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ABSTRACT 


The  U.  S.  Navy  has  recently  embarked  on  a  program  called  Next  Generation  Computer 
Resources  (NGCR)  whose  aim  is  a  cooperative  effort  between  Navy  and  industry  to  field  a 
set  of  state-of-the-art  computers  for  shipboard  use  in  the  late  1990’s.  One  cf  the  important 
feature"  ot  NGCR  is  the  use  ot  commercial  hardware  developed  to  a  standardized  protocol 
and  ruggedized  for  military  applications.  This  protocol  provides  for  compatibility  between 
machines.  The  machines  themselves  may  be  of  any  architecture  so  long  as  they  can  meet 
the  protocol  requirements  as  specified  by  NGCR.  The  NGCR  protocol,  while  not  fully 
defined,  implies  the  use  of  microprocessor  based  workstations. 

The  Naval  Sea  Systems  Command,  in  an  effort  to  keep  pace  with  combat  system 
software,  desires  experience  in  developing  software  targeted  for  commercially  available 
NGCR  machines  (workstations).  This  study  provides  a  detailed  set  of  initial  requirements 
for  such  a  system.  The  approach  is  to  implement  the  basic  features  of  a  Combat  Direction 
System  (CDS)  on  a  microprocessor  based  workstation.  This  low  cost  CDS  (LCCDS)  will 
initially  be  installed  on  non-combatant  vessels  which  currently  have  no  computer  processing 
capability  at  all.  Eventually  the  LCCDS  may  be  used  to  augment  current  processing 
capability  of  CDS  equipped  combatants  followed  by  future  systems  designed  around  high 
speed  (SAFENET)  networks  of  tactical  workstations.  r _ »  I 
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I.  INTRODUCTION 


The  Low  Cost  Combat  Direction  System  (LCCDS)  project,  sponsored  by  the 
Naval  Sea  Systems  Command  (NAVSEA),  will  implement  the  basic  features  of  a 
Combat  Direction  System  on  a  commercially  available  microprocessor-based 
workstation.  One  of  the  intended  uses  for  the  system  is  on-board  non-combatant 
ships  where  no  automated  combat  information  processing  capability  currently  exists. 

The  increasing  availability  of  small,  powerful  and  relatively  inexpensive 
microprocessor  workstations,  ruggedized  for  military  applications,  makes  some  form 
of  Combat  Direction  System  (CDS)  feasible  for  any  Navy  vessel.  The  U.  S.  Navy 
Combat  Logistics  Force  (CLF)  ships  and  other  fleet  support  vessels  currently  handle 
all  tactical  navigation,  contact  management  and  intelligence  tasks  manually  using  only 
maneuvering  board  and  grease  pencil.  The  LCCDS  will  be  capable  of  filling  this 
information  processing  void,  at  a  fraction  of  the  cost  of  a  full  tactical  CDS. 

The  prime  objective  of  this  thesis  is  to  define  the  environment,  goals,  functions 
and  constraints  of  a  prototype  LCCDS  within  the  context  of  current  CDS  system 

r> 

requirements.  This  is  accomplished  through  a  formal  requirements  analysis  process, 
using  established  software  engineering  methodology,  to  derive  the  proposed  LCCDS 
software  system  as  a  small  subset  of  existing  Combat  Direction  Systems. 

A.  HISTORICAL  BACKGROUND:  NTDS 

Since  World  War  II,  the  development  of  radar  has  produced  spectacular  changes 
in  the  conduct  of  naval  warfare.  Jet  aircraft  replaced  their  propeller  driven 
predecessors,  and  the  rate  of  combat  information  increased  exponentially.  The 


magnitude  of  information  that  needed  to  be  assembled  overwhelmed  conventional 
"grease  pencil"  means  and  there  was  an  obvious  need  for  some  type  of  system  or 
technique  to  gather  operational  data,  process  the  data  into  meaningful  and  useful 
information,  and  present  the  information  in  formats  that  facilitated  decision  making  by 
those  to  whom  it  was  presented. 

In  the  late  1950’s,  with  the  inception  of  the  Navy  Tactical  Data  System  (NTDS), 
the  U.  S.  Navy  began  using  computers  in  tactical  shipboard  systems.  The  Naval 
Tactical  Data  System  evolved  from  this  need  to  normalize  and  convert  increasing 
amounts  of  information  from  multiple  sources  (e.g.,  sensors,  navigation  data, 
observation)  to  common  representations  that  could  be  processed,  stored,  and 
disseminated  to  shipboard  tactical  users  so  that  weapons  employment  decisions 
could  be  made  more  effective  with  less  reaction  time. 

When  NTDS  was  first  deployed,  and  during  the  decade  of  the  60’s  its  role  was 
tactical  data  integration.  Tactical  information  generated  was  inconsistent,  mirroring 
the  inefficiencies  and  inaccuracies  of  an  automated  design  concept  largely  manually 
implemented.  NTDS  was  forced  to  interface  with  existing  subsystem  designs  that 
were  subject  to  little  more  than  minor  accommodations  to  it.  The  NTDS  design,  as  a 
result,  represented  a  compromise  heavily  biased  toward  data  conversion  and  limited 
to  serving  as  a  conduit  through  which  personnel  collected,  processed  and  acted  on 
tactical  information.  Uncoordinated  changes  in  the  interfacing  subsystems  caused  a 
continual  catch-up  mode.  IRef.  1] 

Further  study  and  the  experience  of  more  than  two  decades  of  NTDS  history 
resulted  in  the  development  of  Combat  Direction  Systems  with  a  substantial  increase 
in  capabilities  over  the  NTDS. 
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B.  COMBAT  SYSTEMS 


A  ship’s  combat  system  is  typically  thought  of  as  men  and  machines  which  fight 
the  ship.  This  could  be  seen  as  both  weapons  and  the  means  by  which  weapons  are 
controlled.  Subsystems  such  as  navigation  and  communications,  which  are  not 
directly  involved  in  weapons  control,  also  play  an  important  part  in  current  combat 
systems.  The  combat  system  can  then  be  seen  as  the  payload  carried  by  a  Navy 
warship.  It  is  the  composite  of  shipboard  elements  and  personnel  that  includes, 
either  actively  or  passively,  detection,  tracking,  identification,  processing,  evaluation 
and  control  of  engagement  of  hostile  threats.  In  terms  of  equipment,  the  combat 
system  may  include  subsystems  containing  missiles,  guns,  sensors,  electronic 
warfare  (EW),  navigation  and  communication  systems. 

1.  Combat  Direction  Systems  (CDS) 

A  Ship’s  Combat  Direction  System  is  organized  to  direct  combat.  Its 
resources  include  personnel,  equipment  (hardware  and  software),  communications 
and  logistic  support  facilities.  The  CDS  and  the  sensor  and  weapons  systems  it 
controls  are  part  of  the  Combat  System.  CDSs  are  defined  as  follows  [Ref.  2:p.  3-5]: 

Those  combinations  of  data  and  men  handling  the  systems,  either 
manual  or  automated,  employed  to  execute  the  combat  direction 
functions.  They  support  command  at  levels  from  the  platform  (ships, 
aircraft,  submarines)  up  to,  and  including,  task  group/force. 

A  CDS  consists  of  a  complex  set  of  data  inputs,  user  consoles, 
converters,  adapters  and  radio  terminals  interconnected  with  high  speed 
general  purpose  computers  and  their  stored  programs.  Combat  data  are 
collected,  processed  and  composed  into  a  picture  of  the  overall  tactical 
situation  that  enables  the  force  commander  to  make  rapid  and  accurate 
decisions. 
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A  high  level  goal  for  the  CDS  can  be  stated  as  follows:  Optimize  the  individual 
ship’s  fighting  capability  in  concert  with  the  other  segments  of  the  ship’s  combat 
system  [Ref.  2:p.  3-7 1. 

In  general,  the  CDS  role  is  composed  of  the  following  [Ref.  2:p.3-7]: 

(1)  The  automated  shipboard  database  manager  of  tactically  significant 

tracks. 

(2)  The  primary  combat  system  element  supporting  the  Combat  Direction 

Center  (CDC). 

2.  Low  Cost  Combat  Direction  System  (LCCDS) 

Recently  the  U.  S.  Navy  has  initiated  the  Next  Generation  Computer 
Resource  (NGCR)  program  which  is  a  cooperative  effort  between  Navy  (NRAC)  and 
industry  to  field  a  set  of  state-of-the-art  computers  for  shipboard  use  in  the  late 
1990’ s  [Ref.3].  In  their  briefings  with  CNO,  SPAWAR,  NAVAIR,  NAVSEA,  HASC 
and  numerous  DoD  contractors,  the  NGCR  Panel  made  the  following 
recommendations: 

-  The  Navy  should  mandate  widely  used  commercial  standards  for  its 
computing  resources.  The  Navy  should  resist  the  temptation  to  have  its 

"  own  unique  standards. 

-  The  Navy  should  encourage  the  use  of  ruggedized  equipment.  Many 
mission  critical  systems  operate  in  protected  environments  where  full 
militarization  is  too  much  of  a  price  to  pay  for  up-to-date  performance. 

-  The  Navy  should  move  toward  rapid  elimination  of  Government  Furnished 
Equipment  (GFE)  status  of  the  UYK  computers....  Rewriting  existing  UYK 
software  in  Ada  should  be  considered  seriously. 
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-  The  Navy  should  mandate  standards  at  the  system  level  only.  Mandating 
Navy-wide  standards  at  a  lower  level  can  be  counterproductive. 

-  The  Navy  should  reorient  its  planned  prototyping  effort.  The  purpose 
should  be  to  demonstrate  commercial  standards  at  work  and  to  support  the 
upgrading  of  computing  capability  on  current  ships. 

In  particular,  the  prototyping  of  a  weapon  system  using  ruggedized  equipment 

and  commercial  standards  was  recommended.  In  preparation  for  NGCR  availability, 

NAVSEA  wishes  to  gain  some  experience  in  the  development  of  CDS  software  on 

commercially  available  machines  [Ref.  4]: 

The  Navy  desires  to  develop  a  Low  Cost  Combat  Direction  System 
(LCCDS)  that  can  potentially  be  installed  on  non-combatant  ships  or  to 
augment  the  processing  capability  on  board  current  CDS  equipped  ships. 

An  implementation  in  Ada  is  desired.  A  total  of  five  increments  will 
result  in  a  continuously  improving  product  that  reflects  the  desired 
features  of  the  CDS  community.  [Ref.  4] 

The  specific  features  of  the  five  increments  are  as  follow: 

1.  Select  architecture  and  software  support  environment  for  the  LCCDS 
software  system.  Integrate  object  oriented  database  support  and  graphics 
capability. 

2.  Integrate  manual  tracking  and  identification  capability. 

3.  Integrate  a  receive-only  Link  1 1  capability. 

4.  Integrate  an  own  ship  maneuvering  capability. 

5.  Integrate  an  automatic  tracking  capability. 

Enclosure  1  to  Reference  4,  Statement  of  Work  for  the  Low  Cost  Combat 
Direction  System  (LCCDS),  provides  an  informal,  high  level  description  and  is 
included  as  Appendix  A. 
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C.  NAVY  COMMAND  AND  CONTROL  SYSTEMS 

The  navy  has  committed  much  effort  to  the  design  and  development  of  a  standard 
definition  of  the  command  and  control  task.  Specifically,  the  Naval  Space  and  Warfare 
Systems  Command  (SPAWAR)  has  been  developing  the  Navy  Command  and 
Control  System  Afloat  (NCCS-A)  program.  The  NCCS-A  program  encompasses 
several  command  and  control  systems  including  the  Tactical  Flag  Command  Center 
(TFCCj,  Joint  Operational  Tactical  System  (JOTS),  Afloat  Correlation  System  (ACS) 
and  the  Prototype  Ocean  Surveillance  System  (POST).  The  purpose  of  this  program 
is  to  provide  the  Battle  Force/Battle  Group  (BF/BG)  Commander  and  his  subordinate 
warfare  commanders/coordinators  a  consistent,  near  real-time,  tactical  picture  from 
all-source  data,  the  ability  to  access  and  manipulate  the  related  tactical  data,  and  the 
decision  support  tools  required  to  effectively  execute  coordinated  Command  and 
Control  [Ref.  5:p.  1 1. 

CDS  and  NCCS-A  differ  greatly  in  the  areas  of  performance  constraints  and  data 
generation  and  manipulation.  CDS’s  are  deadline  driven  systems  requiring  hard  real¬ 
time  performance.  Different  functionality  is  necessary  in  a  CDS  because  it  must 

l» 

support  a  lower  level  of  tactical  decision-making  needs  and  provide  physical  control 
for  external  systems. 

The  scope,  or  perspective,  in  which  the  tactical  data  will  be  used  is  different  as 
well.  NCCS-A  covers  a  much  larger  scale,  involving  both  organic  and  inorganic 
sources  of  information.  However,  the  types  of  tactical  data  necessary  to  each  are 
identical.  See  Figure  One  for  an  overview  of  how  the  CDS  fits  under  the  "umbrella” 
of  the  larger  scale  naval  command  and  control  systems.  The  CDS  can  be  viewed  as  a 
subset  of  NCCS-A,  dealing  with  the  same  types  of  data,  but  on  a  smaller  scale 
involving  individual  ships  relying  mainly  on  their  own  (organic)  sensors. 
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Figure  1:  Navy  Command  and  Control  Structure 


D.  FORMAL  SOFTWARE  ENGINEERING  APPROACH 

It  is  widely  acknowledged  that  while  the  software  development  process  is  not  a 
rigid  or  narrowly  defined  thing,  there  are  several  essential  ingredients  which  form  the 
basis  of  any  serious  software  development  task.  As  pointed  out  by  Berzins  [Ref.  6] 
these  development  activities  or  ingredients  blend  together  to  form  a  cycle.  Figure  1 
depicts  this  cycle  as  a  data  flow  diagram  where  these  activities  are  pipelined  and 
concurrent.  In  particular,  analysis  continues  throughout  development  and  evaluation. 


Requirements  Analysis  ^ 

1  A 

*  \ 

▼  T 

Functional  Specification 

■ 

♦  \ 

Evolution 

Architectural  Design 

1  A 

i 

i 

T  T 

Implementation 

— J 

Figure  2:  Software  Development  Activity  Cycle 


The  boundaries  between  software  development  activities  are  fuzzy  and  not 
sharply  defined.  The  cycle  is  evolutionary  in  nature  and  never  really  ends  while  the 
system  still  exists.  However,  there  is  a  distinct,  very  clearly  established  starting 
place  for  the  software  development  cycle:  Requirements  Analysis.  The  goals  of 
requirements  analysis  are  to  define  the  purpose  of  the  proposed  software  system  and 
to  determine  the  constraints  on  its  development  [Ref.  6:p.  1.5].  The  requirements 
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analysis  for  the  LCCDS  project  is  based  on  two  assumptions.  First,  a  small, 
simplified  set  of  requirements  can  be  drawn  from  existing  documentation  on  currently 
implemented  (combatant)  combat  direction  systems  [Ref.  7]  where  applicable  to  the 
non-combatant  vessel.  Secondly,  a  large  group  of  knowledgeable,  experienced  U.  S. 
Navy  Surface  Warfare  Officers  are  available  here  at  the  Naval  Postgraduate  School 
who  are  more  than  willing  to  provide  the  necessary  information  and  advice  needed  for 
a  detailed,  realistic  definition  of  the  prospective  LCCDS  "customer"  needs. 

E.  RESEARCH  OBJECTIVES 

The  LCCDS  program  is  in  its  infancy.  With  the  exception  of  the  NAVSEA 
Statement  of  Work,  there  exists  no  documentation  on  the  desired  system.  The  Navy 
organization  primarily  concerned  with  the  development  and  maintenance  of  CDS 
software  is  the  Fleet  Combat  Direction  Support  Activity  (FCDSSA)  located  in  San 
Diego,  CA  and  Dam  Neck,  VA.  FCDSSA  has  provided  much  technical  data  on 
currently  implemented  systems,  but  has  no  immediate  plans  for  involvement  with 
LCCDS  [Ref.  8].  The  obvious  first  step,  therefore,  is  to  provide  a  detailed  definition 
of  LCCDS. 

The  final  product  of  this  initial  phase  of  research  is  an  analysis  of  LCCDS 
requirements  which  accurately  reflects  the  real  CDS  needs  of  non-combatant  vessels 
while  remaining  within  the  constraints  of  a  prototype  research  effort.  The  objective  is 
to  provide  the  following  set  of  results:  [Ref.  6:p.  2-1] 

(1)  A  simplified  model  of  the  prototype  system’s  environment. 

(2)  A  description  of  the  goals  of  the  system  and  the  functions  it  must  perform. 

(3)  Performance  constraints  on  the  prototype  system. 


(4)  Constraints  on  the  environment  and  implementation  of  the  prototype  system. 

(5)  Recommended  design  approaches  based  on  available  technology  and  fleet 
experience  with  existing  systems. 

It  is  hoped  that  the  analysis  provided  by  this  research  will  be  used  as  the 
foundation  for  a  prototype  development  effort  for  LCCDS  based  on  software 
engineering  principles. 

F.  ORGANIZATION 

Chapter  II  provides  the  central  element  of  this  research,  an  analysis  of  initial 
requirements  in  the  form  of  a  hierarchical  set  of  high-level  and  refined  system  goals 
for  the  prototype  LCCDS.  The  primary  emphasis  is  on  a  definition  of  the  software 
system. 

Chapter  III  provides  a  high-level  structural  analysis  of  the  LCCDS  using  the 
Yourdon  model.  It  contains  the  main  data  flow  diagrams  and  the  data  dictionary  to 
model  the  proposed  software  system. 

Chapter  IV  focuses  on  the  underlying  design  concepts  and  issues  related  to 
development  of  an  appropriate  man-machine  interface  (MMI). 

Chapter  V  provides  further  discussion  on  the  formal  software  engineering 
approach  to  large  software  system  development  and  recommendations  for  further 
LCCDS  work. 

LCDR  Seveney  focused  on  requirements  analysis  for  the  man-machine  interface 
and  overall  system  design  constraints.  LCDR  Steinberg  concentrated  on  a 
developing  a  set  of  basic  CDS  requirements  and  an  object  definitions  for  the  tactical 
database.  Both  contributed  to  the  system  architectural  analysis  in  Chapter  III  and 
conclusions  on  the  future  of  the  LCCDS  in  Chapter  V. 
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II.  LCCDS  REQUIREMENTS  ANALYSIS 


A.  LCCDS  TASK  OVERVIEW 

The  system  development  will  follow  the  steps  as  outlined  by  Berzins  [Ref.  6).  It 
is  assumed  that  the  reader  is  familiar  with  the  sequence  and  purpose  of  each  step. 
The  complexity  and  size  of  the  system  make  it  necessary  to  concentrate  on  the 
Requirements  Analysis  as  the  initial  step.  A  high  level  problem  statement  is  given 
in  the  NAVSEA  Statement  of  Work  [Ref.  4:p.  3]: 

The  task  of  the  Low  Cost  Combat  Direction  System  (LCCDS)  is  to 

implement  the  basic  features  of  a  Combat  Direction  System  on  a 

commercially  available  microprocessor  based  workstation. 

This  high-level,  informal  statement  depends  at  least  on  two  concepts  from  the 
application  area  which  are  not  yet  very  well  understood: 

-  What  are  the  basic  features  of  a  Combat  Direction  System? 

-  What  is  the  task  of  the  Low  Cost  Combat  Direction  System  in  terms  of  a 

Combat  Direction  System? 

At  this  point  it  is  necessary  to  provide  informal  statements  on  these  concepts  to 
refine  the  initial  problem  statement  and  to  provide  a  motivation  for  a  better 
understanding  of  the  application  area. 

1.  Features  of  a  Combat  Direction  System 

An  example  of  an  informal  specification  for  a  Combat  Direction  System  is  given  in 
References  7  and  9.  An  individual  ship’s  mission  is  therein  described  by  Required 
Operational  Capabilities  (ROCs)  [Ref.  7:p.  3-37].  ROCs  are  translated  into  a  set 
functions  of  the  Combat  System  together  with  tasks  for  each  function  [Ref.  7:p.  3-5]. 


11 


A  subset  of  the  Combat  Systems  functions  is  allocated  to  the  CDS,  which 
consists  of  hardware,  software  and  personnel  [Ref.  7:p.  3-4],  A  subset  of  the  CDS 
functions  must  be  performed  by  the  CDS  software  system  (CDSWS).  This  subset 
forms  the  basis  of  the  initial  problem  statement  (Figure  3). 


Figure  3  :  Functional  Dependency  for  CDS  Software  Functions 


2.  LCCDS  Definition 

Combat  Logistics  Force  (CLF)  ships  operate  as  logistic  support  components 
of  Battle  Groups  and  Battle  Forces.  Figure  4  shows  that  Combat  Direction  Systems 
(CDS)  are  the  connecting  part  between  the  Combat  System  of  ships.  Battle  Groups 
and  Battle  Forces  [Ref.  2],  Hence,  the  Low  Cost  Combat  Direction  System  has  to 
perform  a  similar  role  for  CLF  ships.  The  role  of  Combat  Direction  Systems  in  Battle 

i* 

Force  Combat  Control  is  defined  in  Reference  2.  A  similar  definition  for  the  LCCDS 

is: 

The  LCCDS  shall  be  the  integrating  part  between  ownship  and  other 
units.  It  shall  consist  of  hardware,  software  and  personnel  to  provide  the 
ship’s  command  personnel  with  a  facility  for  monitoring  the  overall  air, 
surface  and  subsurface  environment.  Force  and  ownship  sensor  data 
shall  be  collected,  correlated  and  evaluated  by  the  LCCDS. 
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The  LCCDS  will  comprise  the  same  set  of  components  as  found  in  combatant 


CDS’s.  The  major  components  of  the  LCCDS  are  depicted  in  Figure  5. 


a.  LCCDS  Hardware 

The  LCCDS  hardware  shall  consist  of  a  commercially  available 
microprocessor  based,  ruggidized  workstation  capable  of  providing  the  required  data 
processing  and  display  capability.  The  workstation  must  satisfy  the  system 
architecture  requirements  as  described  in  Reference  4.  This  includes  in  particular  the 
ability  to  interface  to  external  systems  via  bus  or  network.  The  data  processing 
facility  shall  also  contain  the  peripheral  equipment  necessary  to  provide  the  means  to 
load  the  LCCDS  software  (e.g.,  tape,  disk,  cartridge,  or  optical  disk).  The  data 
display  facility  is  comprised  of  a  data  display  unit  and  the  peripheral  equipment  to 
control  the  LCCDS  initialization,  configuration  and  operation  of  the  LCCDS  (e.g., 
keyboard,  mouse,  trackball,  voice  input,  printer). 
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A  high  resolution,  bit-mapped  19-inch  color  monitor  shall  be  used  for  data 
display.  The  data  display  facility  will  serve  as  the  principal  man-machine  interface 
(MMI)  necessary  for  user  command  and  control  of  the  LCCDS. 
b.  LCCDS  Software 

The  LCCDS  software  shall  be  comprised  of  an  LCCDS  Operational 
Program,  Test  Programs  as  necessary  and  Training  Programs.  For  further  details 
see  Reference  7. 


LCCDS 


Figure  5  :  LCCDS  Components 

c.  LCCDS  Personnel 

LCCDS  personnel  are  those  users  assigned  to  the  LCCDS  operating 
station  as  specified  in  the  ship’s  Battle  Management  Organization.  For  further 
details  see  Reference  7,  page  3-10. 
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B.  INITIAL  PROBLEM  STATEMENT 


This  thesis  is  intended  to  focus  on  the  software  functionality  necessary  to 
implement  CDS  features  on  high  resolution,  bit-mapped  workstation  display 
systems.  The  thrust  of  this  research  is  to  provide  a  detailed  requirements  analysis 
for  the  software  portion  of  the  LCCDS.  We  refer  to  this  as  the  Low  Cost  Combat 
Direction  Software  System  (LCCDSWS).  The  detailed  Initial  Problem  Statement 
can  be  defined  in  terms  of  a  high-level  LCCDS  program  description: 

Develop  the  prototype  of  a  software  system  for  a  Low  Cost  Combat 
Direction  System  (LCCDSWS)  that  implements  the  basic  features  of  a 
Combat  Direction  System  on  a  commercially  available  microprocessor 
based  workstation. 

The  project  development  shall  be  performed  in  five  incremental  steps  as  outlined 

by  the  NAVSEA  Statement  of  Work  [Appendix  A].  These  five  steps,  in  broad  high- 

level  terms,  are  extracted  directly  from  this  Statement  of  Work  and  reflect 

NAVSEA’s  initial  development  plan  and  design  goals.  Figures  6,  7,  8  and  9  depict 

the  LCCDSWS  context  throughout  the  five  incremental  stages  of  development.  The 

following  five  sections  are  extracted  from  the  statement  of  work  and  are  included  to 
•» 

provide  a  high  level  perspective  of  the  "customer’s"  objectives. 

1.  Increment  One 

Select  the  computer  system,  run-time  operating  system  and  software 
support  environment  for  the  LCCDS.  Design/develop  or  select  an  existing 
object  oriented  database  manager  that  interacts  with  the  entire  CDS  data 
base  (as  it  gets  defined)  and  allow  the  user  to  define  new  objects  that  are 
not  part  of  the  CDS  data  base.  The  data  base  manager  should  provide 
features  for  data  entry,  user  friendly  query  language  for  building  logical  and 
arithmetic  relationships  between  data  base  elements,  and  a  powerful 
output  generator  for  developing  display  screens  and  hardcopy  formats. 
Design/develop  a  display  graphics  capability  which  interacts  with  the 
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database  manager  and  provides  the  user  with  the  building  blocks  necessary 
to  define  his  own  customized  screen  formats  for  interactive  operation  of  the 
system.  Display  features  should  include  but  not  be  limited  to  the  following: 

a.  Windows  and  pull  down  menus  for  operation  of  all  program  features  including 
the  operational  features  such  as  mode  selection,  track  information,  help 
commands,  display  doctrine  activation  and  deactivation. 

b.  Window  and  pull  down  menu  selection  controlled  via  mouse,  trackball,  light 
pen,  touch  screen  or  any  other  feature  deemed  usable  by  the  developer. 

c.  Graphics  capability  to  display  all  symbology  defined  in  [Appendix  A], 

d.  Ability  to  overlay  the  track  and  ownship  position  portion  of  the  display  with 
world  vector  shoreline  maps  as  available  from  the  Defense  Mapping  Agency 
(DMA). 

All  pull  down  menu  options  and  window  spaces  should  be  directly 
coupled  with  the  data  base  manager  such  that  all  information  can  be  user 
defined  as  required.  That  is,  the  display  capability  should  be  built  in  generic 
fashion  such  that  the  user  can  tailor  all  display  presentations  including  all 
pull  down  menu  options  and  window  spaces  effectively  building  a  new  run¬ 
time  Man  Machine  Interface  (MMI)  as  desired. 

Display  doctrine  is  a  feature  which  enables  the  user  to  define  the 
conditions  under  which  data  will  be  displayed  and  how  to  present  the 
displayed  data.  Doctrine  statements  should  be  IF  -  THEN  -  ELSE  type 
statements  where  the  IF  clause  provides  for  operations  on  tactical 
information  such  as  type,  speed  and  bearing  of  tracks  to  be  displayed.  The 
THEN  clause  provides  for  the  data  presentation  such  as  blink  the  symbol, 
enlarge,  bold  type,  etc.  Doctrine  should  be  simple  to  define  and  easily 
activated  or  deactivated.  Doctrine  statements  should  be  allowed  to  be 
defined  individually  and  combined,  if  desired,  into  a  doctrine  tree  which 
consists  of  up  to  twelve  different  statements.  The  IF  clause  of  a  doctrine 
statement  should  allow  for  at  least  twelve  qualifiers. 

The  general  response  time  to  any  user  selected  display  option  should 
be  no  greater  than  one  half  second. 
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2.  Increment  Two 


Integrate  a  Manual  Tracking  and  Identification  capability  to  the  basic 
display  capability.  Manual  Tracking  and  Identification  refers  to  the  ability  of 
the  system  to  user  to  build  and  display  a  set  of  geographically  stable  and/or 
moving  points  of  information  of  the  position  portion  of  the  display.  Manual 
Tracking  and  Identification  will  include  but  not  be  limited  to  the  following 
features: 

a.  Maintain  the  ownship  symbol  in  the  center  of  the  position  display  at  all  times. 

b.  Introduce  a  standard  display  symbol  (see  Appendix  A)  at  the  current  location 
of  the  cursor.  All  symbols  should  be  maintained  relative  to  the  ownship 
symbol. 


SHORELINE 

DATABASE 

INTERFACE 


r 

OODBMS 

MMI 

^^^user~^^^ 


Figure  6  :  Context  Diagram  for  LCCDSWS,  Increment  I  and  II 


c.  Allow  the  user  to  assign  speed  and  bearing  to  a  vehicular  track.  Display  a 
proportioned  speed  leader  on  the  track  and  change  its  position  at  least  once 
every  four  seconds.  Track  position  should  be  dead  reckoned  using  the  current 
track  bearing. 

d.  Allow  the  user  to  assign  additional  information  to  any  type  of  track. 
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e.  Allow  a  currently  displayed  track  to  be  hooked  (selected)  and  display  selected 
additional  information  in  a  window  (  e.g.,for  a  hooked  air  track  display  speed, 
bearing,  type,  route,  etc.).  This  additional  information  will  be  an  object  from  a 
user  defined  window. 

f.  Allow  the  user  to  change  the  Identity  of  a  track  (e.gvfrom  unknown  to  friendly). 

g.  Provide  for  an  expandable  track  file  with  no  artificial  size  limitations. 

3.  Increment  Three 

Include  an  ownship  maneuvering  capability  which  includes  navigation 
capability  and  track  interface  information.  Ownship  maneuvering  will 
include  but  not  be  limited  to: 

a.  Allow  for  the  specification  of  up  to  six  steaming  routes  with  up  to  50 
waypoints  (destinations)  per  route. 


Figure  7  :  Context  Diagram  for  LCCDSWS,  Increment  I,  II  and  III 


b.  Provide  Closest  Point  of  Approach  (CPA)  geometry  from  ownship  to  any  track 
and  between  any  two  tracks.  Display  bearing  lines  on  the  position  display 
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4.  Increment  Four 


Integrate  an  organic  auto  tracking  capability  using  the  (TBD)  radar 
interface.  The  task  entails  the  development  of  an  interface  to  a  ship 
mounted  radar,  parsing  the  input  information  and  displaying  the  ship  contact 
information  on  the  position  display.  This  feature  should  not  be  costed  at 
this  time  but  the  implementation  should  be  considered  for  easy  add  on  at  a 
later  date.  A  radar  IDS  will  be  provided  under  a  different  cover. 


Figure  8  :  Context  Diagram  for  LCCDSWS,  Increment  I,  II,  III  and  IV 


5.  Increment  Five 

Integrate  a  receive  only  Link  1 1  capability  which  provides  for  the 
receipt  and  display  of  track  information  from  the  Ship  to  Ship  digital  data 
link.  This  increment  will  entail  the  development  of  an  interface  to  a  Link  1 1 
system  via  NTDS  protocol,  parsing  Link  1 1  messages  and  displaying 
parsed  track  information  on  the  position  display.  It  is  not  expected  that  the 
LCCDS  will  package  and  ship  locally  generated  tracks  for  output  on  the 
data  link.  This  will  be  a  receive-only  system.  The  specific  format  of  the  Link 
1 1  data  is  specified  in  a  classified  Interface  Design  Specification  (IDS)  and 
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Operations  Specification  and  will  be  provided  under  a  different  cover.  For 
quote  purposes  assume  twelve  message  types  and  six  variations  on  each 
message  type.  NTDS  interface  boards  are  commercially  available  and  will 
not  require  a  hardware  development  effort. 


Figure  9  :  Context  Diagram  for  LCCDSWS,  Increments  I  through  V 


C.  ENVIRONMENT  MODEL 

1.  Preface 

The  environment  model  defines  the  concepts  needed  to  describe  the  world  in 
which  the  proposed  system  will  operate  [Ref.  6].  The  term  "system"  refers  to  the 
LCCDSWS  in  this  context.  The  LCCDSWS  shall  be  defined  using  the  vocabulary  of 
the  existing  CDSs  and  their  environment  as  described  in  [Refs.  2,  7  and  9].  Figure 
10  provides  a  view  of  LCCDS  within  the  context  of  its  external  interfaces. 
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Figure  10:  Initial  Context  Diagram  for  LCCDS 
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2.  Terms  and  Definitions 


-  The  LCCDS  shall  provide  the  user  with  a  facility  to  monitor  the  overall  air, 
surface  and  subsurface  environment. 

-  The  LCCDS  shall  collect,  correlate  and  evaluate  force  and  ownship  sensor 
contact  information. 

-  The  LCCDSWS  is  the  software  system  of  the  LCCDS. 

-  The  LCCDSWS  shall  support  a  data  display  facility  to  implement  the  MMI 
described  in  increment  one  by  providing  a  graphic  presentation  of  graphic 
objects,  icons,  symbols  and  alphanumerics. 

-  The  LCCDSWS  shall  be  an  automated  shipboard  database  manager  of 
tactically  significant  tracks. 

-  It  will  interact  with  the  user,  the  tactical  database,  the  Navigation  System, 
the  Radar  System,  the  Link  1 1  System  and  the  Shoreline  Database. 

-  The  Navigation  System  is  a  device  that  provides  the  system  with  ownship 

information  in  terms  of  present  geographical  position,  course,  speed  and  time. 

-  The  Radar  System  is  a  device  that  provides  the  system  with  ownship  sensor 

contact  information  in  terms  of  bearing  and  distance. 

-  Th£  Link  II  System  is  a  device  that  provides  the  system  with  external 

information  on  tracks  in  terms  of  geographical  position,  course,  speed,  time, 
track  number  and  track  identity. 

-  The  Shoreline  Database  is  a  device  that  provides  the  system  with  external 

information  on  shorelines. 

-  Geographical  positions  are  positions  relative  to  the  earth’s  surface  expressed 

in  terms  of  latitude  and  longitude. 

-  A  Relative  Position  is  a  position  expressed  in  terms  of  range  and  bearing 
from  an  arbitrary  point. 
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Course  is  the  angle  between  true  north  and  the  direction  in  which  a  ship 
submarine  or  aircraft  proceeds. 

True  Bearing  is  the  angle  between  true  north  and  an  imaginary  line  between 
two  objects. 

Relative  Bearing  is  the  angle  between  the  bow  of  Ownship  and  an  imaginary 
line  between  Ownship  and  another  object. 

A  track  is  a  representation  of  some  environmental  phenomena  converted  into 
accurate  estimates  of  geographical  position  with  respect  to  time,  course, 
speed,  depth  and  height  if  applicable.  A  track  is  further  described  by  a  track 
number,  track  identity  and  category. 

A  vehicular  track  is  any  object  with  attributes  course  and  speed. 

Dead  Reckoning  is  the  estimation  of  a  ship’s  position  based  on  its  course  and 
speed  and  not  from  observation. 

Track  number  is  a  positive  integer  uniquely  related  to  each  track. 

Track  identity  classifies  each  track  as  one  of  the  following:  Friend,  Hostile, 
Unknown  and  Special. 

Track  category  classifies  each  track  as  one  of  the  following:  Tentative,  Air, 
Surface,  Subsurface  and  Special. 

P 

The  Closest  Point  of  Approach  (CPA)  is  the  position  of  a  vehicle  in  range,  true 
or  relative  bearing  and  time  to  another  vehicle,  when  the  two  vehicles  will  be 
closest  to  each  other. 

The  Data  Link  Reference  Point  is  a  fixed  geographic  position  representing  the 
origin  of  a  cartesian  coordinate  system  in  which  track  positions  are  reported. 

Special  Points  are  a  set  of  NTDS  defined  symbols,  other  than  vehicular 
tracks,  which  supports  the  user  in  establishing  a  complete  picture  of  the 
tactical  environment.  They  may  be  fixed  to  a  geographic  point,  or  move  with 
any  valid  course  and  speed. 
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The  Man-Machine  Interface  is  that  composition  of  hardware  and  software 
designed  specifically  to  transform  computer  processed  data  into  conceptual 
blocks  of  human  understandable  information,  and  act  on  the  human  response  to 
this  information. 

A  user  is  any  crewmember  designated  to  operate  the  LCCDS  for  the  purpose 
of  providing  the  necessary  information  for  quick,  accurate  tactical  decision¬ 
making. 

A  sensor  is  any  device  which  somehow  scans  the  external  environment 
surrounding  LCCDS  and  detects  a  certain  class  of  tactically  significant 
phenomena. 

The  Hook  function  identifies  a  position  on  the  TacPlot  selected  for  some 
program  action.  Hooking  an  object  is  a  standard  NTDS  user  action  and  is 
described  in  further  detail  in  G  1.2. 1.1.2. 

A  Tactical  Plot  (TacPlot)  is  a  graphical  representation  of  the  spatial 
relationship  between  ownship  and  tactically  significant  tracks  with  respect  to 
relative  and  geographic  position. 

A  TacPlot  is  a  window  for  graphical  input  and  output  generated  by  the  MMI. 

A  symbol  is  the  graphical  representation/output  on  the  TacPlot  of  an  object 
within  the  object  oriented  database  management  system  (OODBMS). 

A  graphical  input  to  the  OODBMS  is  an  input  performed  by  the  user  on  the 
T&cPlot  by  selecting  a  position  on  the  TacPlot  with  the  Ball  Tab. 

An  object  qualifies  for  graphical  representation! display  output  on  the 
TacPlot  when  its  geographical  position  is  in  the  set  of  geographical  positions 
determined  by  the  ownship  geographical  position  and  the  range  selected  for 
that  TacPlot. 

An  alphanumerical  window  is  a  window  for  alphanumerical  input  and  output 
generated  by  the  MMI. 

Alphanumerical  input  and  output  to  and  from  the  OODBMS  is  the  entry  and 
retrieval  of  a  set  character  strings  associated  with  an  object  within  the 
OODBMS. 


24 


-  The  attribute  Origin  describes  the  source  of  a  track/special  point  object: 

-  Local  Manual  denotes  an  object  who’s  source  is  user  input. 

-  Local  Auto  denotes  an  object  who’s  source  is  an  ownship  sensor. 

-  Remote  denotes  an  object  who’s  source  is  external,  in  particular  Link  11. 


D.  LCCDSWS  GOALS 

To  derive  the  high  level  goals  we  use  the  initial  problem  statement  along  with 
specific  guidance  as  provided  by  NAVSEA  [Ref.  4]  and  current  CDS  requirements 
documentation  [Ref.  2,  7  and  9].  We  assume  that  the  reader  is  familiar  with  CDS 
terminology  and  the  role  and  organization  of  the  LCCDS. 

G  1:  Man-Machine  Interface 

The  system  has  to  provide  a  flexible,  easy  to  use,  window  based  user 
interface.  We  refer  to  this  function  as  the  Man-Machine  Interface  (MMI) 
Function.  This  goal  will  be  implemented  as  part  of  Increment  One. 

G  1.1:  Provide  Tools  for  Interactive  Operation 

The  system  shall  provide  the  user  with  the  tools  necessary  to  define  his 
own  customized  screen  formats  for  interactive  operation  of  the  system.  This 
'capability  shall  parallel  current  development  for  the  Navy  Command  and 
Control  Station  (NCCS-A). 

G  1.2:  Provide  Consistency  with  Standard  Display 

The  system  shall  provide  the  basic  features  of  a  standard  navy  display 
console. 

G  1.3:  Provide  a  Display  Doctrine 

The  system  shall  provide,  via  a  Display  Doctrine ,  the  capability  for  user 
defined  conditional  statements,  in  IF-THEN  form,  which  control  data 
filtering  and  specify  presentation  parameters  for  displayed  data. 
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(SI  2:  System  Control 


The  system  has  to  control,  initialize  and  monitor  the  LCCDS  hardware, 
software  and  operator  configurations.  We  refer  to  this  function  as  the 
System  Control  Function. 

G  3:  Tactical  Database 

The  system  shall  provide  a  Tactical  Database.  We  refer  to  this  function  as 
the  Tactical  Database  Function.  This  goal  will  be  implemented  as  part  of 
Increment  One. 

G  3.1:  Integrate  OODBMS  into  LCCDSWS 

The  Tactical  Database  shall  be  an  object-oriented  database  management 
system  (OODBMS).  It  shall  be  an  integral  part  of  the  LCCDSWS. 

G  3.2:  Provide  a  Set  of  Object  Types 

The  OODBMS  shall  provide  a  set  of  object  types. 

G  3.3:  Allow  Definition  of  new  Object  Types 

The  OODBMS  shall  allow  the  user  to  define  new  object  types  at  runtime. 

G  3.4:  Provide  Input  and  Output  for  OODBMS 

The  OODBMS  shall  provide  features  for  data  input  and  output. 

G  3.5:  Provide  a  Query  Language  for  the  OODBMS 

The  OODBMS  shall  provide  a  user  friendly  query  language  for  building 
'  logical  and  arithmetic  relationships  between  database  objects. 

G  4:  Basic  CDS  Function 

The  system  must  support  the  user  to  establish  an  accurate  picture  of  a 
ship’s  environment.  We  refer  to  this  function  as  the  Basic  CDS  Function. 
This  goal  will  be  implemented  as  Increments  Two,  Three,  Four  and  Five. 

G4.1:  Ownship  Monitor  Function 

The  system  has  to  monitor  the  ships  surface  operations.  We  refer  to  this 
function  as  the  Ownship  Monitor  Function.  This  goal  will  be  implemented 
as  Increment  Three. 
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G  4.2:  Tracking  Function 

The  system  has  to  update  the  position,  determine  course  and  speed  and 
height  and  depth  of  applicable  tracks.  We  refer  to  this  function  as  the 
Tracking  Function.  This  goal  will  be  implemented  as  part  of  Increment  Two. 

G  4.3:  Identification  Function 

The  system  has  to  support  the  determination  of  category  and  identity  of 
applicable  tracks.  We  refer  to  this  function  as  the  Identification  Function. 
This  goal  will  be  implemented  as  part  of  Increment  Two. 

G  4.4:  Search  and  Detection  Function 

The  system  has  to  accept  tracks  and  sensor  contact  informations  provided 
by  ownship  sensors.  We  refer  to  this  function  as  the  Search  and  Detection 
Function.  This  goal  will  be  implemented  as  Increment  Four. 

G  4.5:  Communication  Function 

The  system  shall  support  the  establishment  and  maintenance  of  digital 
communications  (Link  1 1  receive  only).  We  refer  to  this  function  as  the 
Communication  Function. 

G  4.6:  Tableau  System  Function 

The  LCCDSWS  shall  provide  detailed  information  on  all  aspects  of  the 
tactical  situation  and  system  control,  operating  parameters  and  status. 
This  information  is  obtained  from  the  Tactical  Database,  the  user,  external 
interfaces  and  various  system  parameters.  It  shall  be  indexed  for  easy  user 
'  access  and  presented  in  tableau  form  using  Alphanumeric  I/O  windows.  We 
refer  to  this  function  as  the  Tableau  System  Function. 

G  5:  Incremental  Development 

The  system  shall  be  modularized  to  allow  an  implementation  in  incremental 
steps. 

G  6:  Concurrency  and  Extensions 

The  system  shall  be  highly  concurrent  and  prepared  for  future  extensions. 
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E.  LCCDSWS  PROTOTYPE  CONSTRAINTS 


One  of  the  primary  goals  of  requirements  analysis  is  to  determine  the  constraints 
to  be  imposed  on  the  proposed  system.  Constraints  limit  the  range  of  choices 
available  to  the  system  developer  and  set  the  boundary  conditions  for  system 
capability.  A  clear  definition  of  constraints  is  essential  to  properly  understand  the 
trade-offs  which  will  be  necessary  to  resolve  the  inevitable  conflicts  with  the  stated 
goals  of  the  system.  The  typical  constraint  types  are  Resource,  Implementation  and 
Performance  [Ref.  6:p.  2-6].  Additional  constraint  types,  regarding  tactical  data 
formats,  units  of  measure  and  standardization  are  included  to  help  define  the 
environment  in  which  the  user  must  interpret  the  data  presented.  The  following  list  of 
general,  high-level  constraints  provides  a  brief  perspective  of  LCCDS  capability  and 
limitations.  These  are  described  in  greater  detail  in  later  sections: 

Cl:  Resources 

The  level-of-effort  NPS  can  provide  the  LCCDS  program  is  limited  only  by 
the  number  of  students  interested  in  pursuing  research  related  to  the 
program. 

C2:,  Implementation 

The  Low  Cost  Combat  Direction  Software  System  (LCCDSWS)  prototype 
shall  be  implemented  in  Ada  with  an  emphasis  on  use  of  commercial 
software,  interfaced  with  Ada,  for  portable  database  and  user  interfaces. 

C3:  Performance 

System  response  shall  ^  sufficiently  fast  ,  and  predictable  under  varying 
system  loading  to  supp^a  critical  decision  making  reliably  in  a  highly 
stressful,  rapidly  changing  tactical  environment. 
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C4:  Tactical  Data  Representation 

The  LCCDS  Man-Machine  Interface  (MMI)  shall  represent  all  tactical 
symbology  and  data  in  a  manner  consistent  with  NTDS  standardization  and 
current  fleet  training  conventions. 

C5:  Interface  Compatibility  and  Standardization 

The  LCCDSWS  shall  provide  the  basic  features  of  a  CDS  using  existing 
standards  as  guidance  for  establishing  a  man-machine  (MMI)  interface 
"look  and  feel"  which  is  consistent  with  other  Navy  command  and  control 
systems. 

1.  Resource  Constraints 

Resource  constraints  are  administrative,  rather  than  technical,  in  nature.  They 
consist  mainly  of  development  schedules  and  milestones  to  be  met  and  funding  limits 
for  the  project.  One  of  the  major  purposes  of  requirements  analysis  is  to  provide 
early  warning  when  it  appears  that  required  goals  and  functions  of  the  proposed 
system  cannot  be  met  given  the  time  and  money  constraints. 

At  this  rime  the  LCCDS  effort  at  the  Naval  Postgraduate  School  is  in  the  form 
of  unfunded  thesis  work  conducted  by  graduate  students.  Thus,  there  is  no  formal 
schedule  to  be  met,  nor  any  budget  concerns. 

2.  Implementation  Constraints 

Implementation  constraints  are  normally  imposed  on  the  system  designer  by 
the  customer.  They  concern  hardware,  operating  systems,  external  systems  (i.e., 
existing  interfaces),  programming  languages  and  design  standards. 

a.  Prototype  Hardware 

The  Naval  Postgraduate  School  has  decided  to  use  the  Sun  Microsystems 
Sparcstation  1  (RISC)  machine  for  LCCDSWS  prototype  development.  The  selection 
of  this  particular  hardware  suite  was  based  on  the  following  criteria: 
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-  The  Sparcstation  1  meets  the  preliminary  standards  recommended  for 
NGCR  computers  [Ref.  4], 

-  Ruggidized  versions  of  the  Sun  workstations,  capable  of  meeting 
military  standards,  are  commercially  available  today  [Ref.  10]. 

-  Sun  workstations  are  widely  available  within  the  Computer  Technology 
Department,  networked  together  via  Ethernet. 

-  Students  are  familiar  with  the  Sun  systems. 

b.  Operating  System 

The  Naval  Postgraduate  School  will  use  the  UNIX  operating  system  as 
adapted  by  Sun  Microsystems  to  support  the  use  of  windows  for  their  workstations. 
The  Sun  operating  system  is  derived  from  the  UC  Berkeley  Version  4.2BSD  and  Bell 
Lab’s  UNIX  System  version  32V  [Ref.  ll:p.  10].  Use  of  a  UNIX  based  operating 
system  for  prototype  LCCDS  software  was  based  on  the  following  criteria: 

-  UNIX  based  operating  systems  are  well  known  and  widely  available  to 
system  developers. 

-  Software  applications  developed  using  UNIX  are  highly  portable.  There 
exists  a  great  deal  of  information  on  how  to  design  applications  which 
will  port  easily  to  most  UNIX  derived  operating  systems  [Ref.  12].  The 
software  developed  at  NPS  shall  be  directly  usable  on  any  UNIX  based 
hardware  suite. 

The  drawback  in  using  UNIX  for  the  prototype  is  that  it  does  not  provide 
mechanisms  for  guaranteeing  real-time  performance.  There  are,  however  several, 
UNIX-derived  operating  systems  commei  dally  available,  which  provide  real-time 
scheduling  capability  and  retain  compatibility. 

c.  Implementation  Language 

In  accordance  with  DoD  policy  and  as  specified  in  the  NAVSEA  Statement 
of  Work  (Appendix  A),  Ada  shall  be  used  as  the  implementation  language  for 
LCCDSWS. 
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d.  Commercial  Software 

As  recommended  by  the  NGCR  [Ref.  3],  maximum  use  of  existing 
commercial  software  shall  be  utilized  in  the  development  of  the  LCCDS  prototype. 
Specifically,  use  of  commercial  window  and  database  management  software  shall  be 
explored. 

e.  External  Interfaces 

As  specified  by  NAVSEA  [Appendix  A],  the  LCCDS  shall  eventually  be 
capable  of  interfacing  with  existing  shipboard  navigation,  radar  and  Link  11 
equipment.  These  can  be  viewed  as  "passive"  interfaces  in  that  LCCDS  will  receive 
data  from,  but  not  provide  control  of,  these  external  systems. 

The  database  systems  interfaces  and  the  user  interface  shall  be 
considered  as  part  of  the  LCCDS WS.  As  stated  in  subparagraph  d  above,  the 
database  and  windowing  capabilities  shall  take  advantage  of  available  commercial 
software  to  the  maximum  extent  possible. 

/.  Detailed  Implementation  Constraints 
C2: 

'The  Low  Cost  Combat  Direction  Software  System  (LCCDSWS)  prototype 
shall  be  implemented  in  Ada  with  an  emphasis  on  portability  and  use  of 
commercial  software  interfaced  with  Ada,  for  database  and  user  interfaces. 

C2.1: 

The  4.2BSD  UNIX  operating  system,  as  implemented  in  the  Sun 
Microsystems  Sparcstation  1,  shall  provide  the  LCCDSWS  run-time 
environment  and  host  hardware  for  prototype  development. 

C2.2: 

The  user  interface  shall  be  designed  using  current  windowing  technology 
available  on  microprocessor  based  workstations.  The  use  of  commercial 
window  management  software,  interfaced  with  Ada,  is  emphasized. 
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C2.3 


The  Tactical  Database  shall  be  object-oriented,  allowing  all  associated 
track  data  (text,  graphics,  functions)  to  be  stored  as  a  single  entity.  The 
database  shall  be  designed  to  utilize  dynamically  allocated  storage. 
Maximum  number  of  stored  tracks  shall  be  limited  only  by  physical  memory 
availability. 

C2.4 

The  prototype  LCCDSWS  shall  be  developed  under  the  assumption  that 
the  host  environment  will  be  different  from  the  development  environment. 
Therefore,  the  system  must  be  portable,  supporting  maximum  independence 
from  development  hardware. 

3.  Performance  Constraints 

Performance  constraints  may  be  viewed  from  several  different  levels.  The 
LCCDS  is  primarily  an  interactive  system  and  therefore  must  provide  fast,  predictable 
response  to  operator  demands.  At  the  system  level,  performance  constraints  specify 
maximum  program  size  (memory  space  required),  reliability  and  performance  under 
various  conditions  of  system  degradation  (e.g.,  casualty  modes  of  operation 
available). 

At  a  lower  (functional)  level,  performance  constraints  are  more  focused.  The 
LCCDS  will  play  a  major  role  in  the  tactical  decision  making  process,  thus  requiring 
hard  real-time  response  for  some  functions.  While  the  prototype  may  not  meet  real¬ 
time  reliability  constraints,  as  explained  in  the  previous  section,  the  software  will  be 
developed  as  a  real-time  system  with  specific  timing  constraints  associated  with 
critical  functions. 

a.  Real-Time  Performance 

For  the  purposes  of  the  LCCDS  real-time  performance  means  providing 
guaranteed  response  to  external  input  and  user  demands  within  the  specified  timing 
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constraints.  The  LCCDS  shall  be  viewed  as  a  deadline  driven  system  where  late 
information  may  be  useless  and  result  in  severe  or  catastrophic  consequences. 

b.  Detailed  Performance  Constraints 

C3: 

System  response  shall  be  sufficiently  fast,  and  predictable  under  varying 
system  loading  to  support  critical  decision  making  reliably  in  a  highly 
stressful,  rapidly  changing  tactical  environment. 

C3.1: 

All  tracks  shall  be  updated  at  least  every  4  seconds. 

C3.2: 

Response  times  for  menu  selections,  track  information  requests,  tactical 
display  aids  (graphic  tools),  etc.,  shall  be  less  than  1  second. 

C3.3: 

The  system  shall  support  up  to  1000  active  tracks/special  points  displayed 
on  the  TacPlot.  The  number  of  tracks/special  points  held  in  the  Tactical 
database  shall  be  constrained  only  by  physical  memory  limits  of  the  system. 

C3.4: 

Display  of  shoreline  maps  on  the  TacPlot  is  not  subject  to  real-time 
performance  constraints. 

4.  Tactical  Data  Representation  Constraints 

Display  constraints  are  imposed  on  the  representation  of  tactical  symbol  and 
data  as  necessary  to  support  standardized  training,  operations  and  communication 
between  CDS  configurations.  Detailed  information  and  guidance  regarding  standard 
display  symbology  for  combat  direction  systems  is  contained  in  the  FCDSSA  CDS 
Standardization  Manual  [Ref.  13]. 

C4: 

The  LCCDS  MMI  shall  represent  all  tactical  symbology  and  data  in  a 
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manner  consistent  with  NTDS  standardization  and  current  fleet  training 
conventions. 

C4.1- 

The  MMI  shall  present  the  tactical  picture  and  associated  data  in  a  manner 
consistent  with  existing  combat  direction  systems. 

C4.1.1: 

All  range  information  shall  be  expressed  in  nautical  miles  (NM)  and/or 
yards  (yds). 

C  4.1.2: 

All  azimuth  (bearing/heading)  information  shall  be  expressed  in  degrees 
(000.00-359.99)  relative  to  either  true  or  magnetic  north  as  indicated  by  an 
uppercase  T  or  M  immediately  following  second  decimal  place  of  the 
number. 

C  4.1.3: 

Altitude  and  depth  information  shall  be  expressed  in  feet  (ft). 

C  4.1.4: 

Time  shall  be  expressed  in  24-hour  clock  digital  format  followed  by  the 
appropriate  upper  case  letter  time  zone  identifier.  The  default  time  zone 
shall  be  Greenwich  Mean  Time  (GMT).  The  user  shall  have  the  option  of 
displaying  current  time  in  any  time  zone. 

0,4. 1.5: 

Geographic  position  shall  be  expressed  in  terms  of  latitude  (north-south) 
and  longitude  (east-west)  degrees,  minutes  and  seconds. 

C  4.1.6: 

Speed  shall  be  expressed  in  knots  (kts). 

C4.2: 

All  LCCDS  terms,  acronyms  and  data  naming  conventions  shall  be  limited 
to  those  commonly  used  and  meaningful  within  the  NTDS  environment. 

5.  MMI  Compatibility  Constraints 

The  LCCDS  MMI,  to  the  maximum  extent  possible,  shall  follow  existing 
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standards  in  regard  to  MMI  design  for  graphics  workstation  applications.  The  most 
current  standard  available  is  the  SPAWAR  Software  Requirements  Specification  for 
the  NCCS-A  Workstation  Executive  [Ref.  5].  This  detailed  specification  provides 
extensive  guidelines  and  design  approaches  for  MMI  development  taking  advantage 
of  current  state-of-the-art  display  technology.  The  obvious  course  of  action, 
therefore,  would  be  to  constrain  the  development  of  LCCDS  to  conform  as  much  as 
possible  to  the  MMI  conventions  specified  for  NCCS-A,  and  fitting  it  to  CDS 
function. 

C5: 

The  LCCDSWS  shall  provide  the  basic  features  of  a  CDS  using  existing 
standards  as  guidance  for  establishing  a  man-machine  (MMI)  interface 
"look  and  feel"  which  is  consistent  with  other  Navy  command  and  control 
systems. 

C5.1: 

The  LCCDS  MMI  development  shall  be  constrained  to  follow  the  form  and 
environment  described  in  Reference  5  to  the  maximum  extent  possible 
while  preserving  the  functional  goals  of  a  CDS  as  described  in  this 
document. 

F.  LCCDSWS  GOAL/FUNCTION  REFINEMENT 

1.  Man-Machine  Interface  (MMI)  Function 
a.  Preface 

The  Man-Machine  Interface  is  the  largest  and  most  complex  portion  of  the 
LCCDSWS.  It  is  here  that  the  machine  touches  the  user.  All  system  control,  function 
and  capability  shall  be  accessed  via  this  MMI.  The  interface  is  primarily  visual, 
providing  the  user  with  graphic  representation  of  tactical  data,  spatial  relationships 
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and  tactical  decision  aids  using  window  based  menus,  cues,  tableaus  and  graphical 
plots. 


b.  Goals/Functions 

The  following  system  goal  statements  reiterate  the  high  level 
requirements  and  refine  the  functional  detail  of  the  MMI. 

G  1:  The  Man-Machine  Interface 

The  system  shall  provide  a  flexible,  easy  to  use,  window  based  user 
interface.  We  refer  to  this  function  as  the  Man-Machine  Interface  (MMI). 
The  MMI  shall  consist  of  a  Tactical  Display,  trackball,  keyboard  and 
associated  software  necessary  for  control  and  manipulation  of  the  tactical 
data  presentation. 

The  Tactical  Display  shall  consist  of  a  set  of  active  windows  displayed  on  a 
19  inch  bit-mapped  color  monitor.  User  control  and  data  I/O  to  the  LCCDS 
shall  be  via  the  MMI. 

The  MMI  shall  provide  the  user  with  tactical  information,  defined  and 
filtered  as  specified  by  a  Display  Doctrine,  and  the  means  to  control  and 
modify  the  system  and  tactical  information  presented.  Figure  11  provides  a 
detailed  depiction  of  MMI  structure  and  components. 


G  1.1:  MMI  Building  Blocks 

'The  system  shall  provide  the  tools  necessary  to  define  customized 
versions  of  the  Tactical  Display  screen  for  interactive  operation  of  the 
system. 

G  1.1.1:  Tactical  Display  Architecture 

Maximum  use  of  current  windowing  technology  shall  be  used  to  implement 
the  Tactical  Display  portion  of  the  MMI. 

Windows  are  rectangular  areas  positioned  on  the  display  screen  in  a 
manner  allowing  the  user  to  arrange  space  and  information  to  best  meet  his 
needs. 

Windows  shall  be  allowed  to  overlap  or  nest  inside  other  windows. 
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Obscured  windows  shall  retain  their  I/O  functions  and  capability. 

Windows  shall  be  mapped  to  any  position  on  the  Tactical  Display  as 
selected  by  the  user. 


Figure  11  :  Man-Machine  Interface  (MMI)  Structure 
* 

Each  window  shall  have  a  stored  set  of  attributes,  referred  to  as  it’s 
Graphic  Context  (GC)  [Ref.  14:p.  39],  which  specify  the  following: 

-  background  color 

-  foreground  color  (text,  graphic  objects,  icons) 

-  window  position  (current  mapping) 

-  window  exposure  state  (exposed  or  hidden) 

-  window  size  (fixed  or  variable) 

-  border  style 
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-  cursor  type  (ball  tab  or  arrow  pointer) 

-  I/O  capability 

Each  window  GC  shall  contain  a  set  of  predefined  default  values  and  be 
user  modifiable. 

User  choices  for  GC  attributes  shall  be  limited  to  remain  within  the 
constraints  set  by  US  Navy  human  factors  guidance. 

G  1.1. 1.1:  Window  Classes 

There  shall  be  three  basic  classes  of  window  each  providing  the  user  with  a 
particular  method  for  performing  I/O;  Functions  I/O,  Graphics  I/O  and 
Alphanumeric  I/O.  The  visual  appearance  and  functionality  of  these  window 
classes  shall  be  implemented  in  accordance  with  the  conventions  described 
in  Goal  1.1. 1.2. 

G  1.1.1. 1.1:  Functions  I/O 

The  Functions  class  includes  pop-up  menus,  icons,  cues  and  alerts  which 
provide  the  user  input,  information  and/or  feedback  on  all  LCCDSWS 
software  functions  and  operations. 

The  user  performs  the  necessary  I/O  using  Trackball  cursor  (Arrow 
Pointer)  and  Hook  functions  to  select  and  activate  menu  choices  or  n^ns 
associated  with  the  desired  system  function. 

Any  function  requiring  the  user  to  complete  a  sequence  of  actions  shall 
provide  menu  driven  choices  in  the  form  of  pop-up/pull-down  windows.  The 
user  shall  be  able  to  directly  access  the  window  for  data  input,  modification 
"  and/or  menu  selections  via  keyboard  or  cursor.  System  reliance  on  user 
memory  shall  he  avoided  to  the  maximum  extent  possible. 

Those  functions  which  are  frequently  used,  repetitive  in  nature,  or  consist 
of  only  one  step  or  choice  of  action  may  be  represented  in  icon  form. 

Visual  cues  and  alerts  signalling  for  user  action,  or  in  response  to  user 
actions  or  requests  shall  be  generated  in  the  form  of  pop-up  windows. 

Any  user  request  or  input  to  the  system  shall  be  graphically  acknowledged 
via  text  windows,  highlighted  menu  choices,  inverse  video,  change  in  cursor 
shape  or  color,  etc.  The  system  shall  provide  timely  feedback,  in  some 
form,  to  assure  the  user  of  pending  program  action  or  response. 
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G  1.1.1. 1.2:  Graphics  I/O 


The  Graphics  I/O  class  provides  for  Plan  Position  Indicator  (PPI)  like 
display  of  tactical  data  and  symbology  in  accurate  spatial  relationship  with 
each  other  and  Ownship  position. 

The  primary  instance  of  this  window  class  is  the  TacPlot. 

User  control  and  manipulation  of  tactical  data  displayed  on  the  TacPlot  shall 
be  via  Trackball  cursor  (Ball  Tab)  and  Hook  functions. 

G  1.1. 1.1.3:  Alphanumeric  I/O 

This  class  provides  alphanumeric  information,  in  tableau  form,  regarding 
detailed  tactical  data  for  Ownship,  all  tracks  held  in  the  Tactical  Database, 
system  status  and  operating  parameters,  display  configuration,  window 
GC’s. 

This  class  shall  provide  the  user  direct  access  to  the  Tactical  Database  for 
information  and  manipulation  of  tactical  data.  The  user  performs  the 
necessary  alphanumeric  input  into  data  tableaus  using  the  keyboard. 

G  1. 1.1.2:  Basic  Conventions  for  the  MMI 

To  aid  in  the  standardization  effort,  the  conventions  for  the  MMI  shall  be 
consistent  with  the  NCCS-A  Workstation  Executive  requirements  [Ref.  5]. 
The  following  is  a  goal  refinement  for  the  LCCDS  MMI  as  derived  from  that 
specification. 

G  1.1. 1.2.1:  User  Interaction  Techniques 

'  Normal  user  interaction  with  the  system  will  be  via  the  trackball  (or  mouse 
if  employed)  and  keyboard.  All  cursor  interaction  shall  be  via  a  three- 
button  trackball  or  mouse,  or  the  cursor  keys  (hereafter  referred  to  as  the 
trackball).  The  trackball  controls  a  cursor  which,  when  interacting  with 
menus,  windows  or  objects  (such  as  tracks),  is  displayed  as  an  arrow 
known  as  the  pointer.  The  actual  shape  of  the  cursor  shall  be  redefined  by 
an  application  for  use  within  the  confines  of  its  own  windows  only.  In  a  text 
window,  the  cursor  will  be  in  form  of  a  vertical  blinking  bar,  in  a  TacPlot 
window  the  cursor  will  be  in  form  of  the  ball  tab  (Goal  1.2. 1.1). 

As  the  trackball  is  moved,  the  cursor  will  follow  on  a  corresponding  path 
across  the  screen.  Certain  trackball  movements,  when  combined  with 
trackball  button  interaction,  are  used  for  system  control. 
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G  1.1. 1.2. 1.1:  Trackball  Interaction  Terminology 

This  goal  describes  the  terminology  required  to  describe  trackball 
interaction: 

(1)  Press: 

Depress  a  trackball  button  and  hold  it  down. 

(2)  Release: 

Release  the  appropriate  trackball  button  to  initiate  the  desired  action. 

(3)  Click: 

When  the  cursor  is  located  over  a  position  or  object  of  interest  on  the 
screen,  a  quick  press  and  release  of  the  trackball  button  creates  a  signal 
recognized  by  the  system  as  a  "click".  Clicking  has  differing  effects 
depending  on  the  cursor’s  location.  In  general  clicking  the  trackball  is 
equivalent  to  pressing  the  return  key  on  the  keyboard.  When  in  a  TacPlot, 
an  object  may  be  selected  by  clicking  the  trackball  button  once.  Clicking  the 
object  a  second  time  deselects  it. 

(4)  Moving  the  Cursor: 

Rolling  the  cursor  with  no  buttons  depressed  or  activated  shall  move  the 
cursor  in  the  corresponding  direction. 

(5)  Dragging  the  cursor: 

* 

This  technique  is  used  to  move  or  reconfigure  an  object  on  the  screen. 
Dragging  is  performed  by  placing  the  cursor  over  the  appropriate  object, 
.clicking  a  trackball  button  and  then  moving  the  cursor.  When  the  desired 
effect  is  accomplished,  the  user  clicks  the  trackball  button  again  and  the 
system  reconfigures  the  screen  image  as  appropriate. 

G  1.1. 1.2. 1.2:  Basic  Interactive  Window  Features 

All  interactive  windows  for  Function-,  Graphics-  and  Alphanumeric  I/O 
shall  be  represented  using  the  following  conventions  in  accordance  with 
Reference  5. 

G  1.1. 1.2.1. 2.1:  Basic  Window  Interaction 

Interactive  windows  shall  be  designed  using  the  basic  building  blocks  as 
described  in  the  following  paragraphs.  These  window  features  are  depicted 
in  Figure  12. 
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(1)  Close  Box: 

The  Close  Box  is  a  small  square  icon  which,  when  located  in  the  left-hand 
comer  of  the  title  bar,  shall  be  used  to  close  the  application  window. 
Clicking  on  it  means  no  further  processing  by  this  application  window  is 
required  and  to  close  the  window.  If  the  user  has  performed  any  editing  or 
changed  any  settings,  the  user  will  be  asked  whether  he  wishes  to  save  the 
changes  made. 

(2)  Iconify  Box: 

This  box  is  a  small  square  object  resembling  a  four-pane  window  located  on 
the  right  end  of  the  title  bar.  When  the  user  clicks  the  iconify  box,  the 
window  shall  shrink  to  icon  size  and  move  to  the  upper  left-hand  side  of 
the  root  window.  This  feature  shall  only  be  used  in  applications  which  either 
require  user  initiation  and  then  can  run  in  the  background,  or  may  be 
interrupted  to  perform  other  processing.  The  user  shall  be  able  to  move  the 
application  icon. 

(3)  Resize  Box: 

This  box  is  a  small  icon  consisting  of  three  squares  of  decreasing  size 
which,  when  located  in  the  lower  right  comer  of  the  application  window, 
may  be  used  to  resize  the  window.  It  shall  be  activated  and  used  by 
dragging  the  cursor.  As  the  cursor  is  moved,  it  shall  drag  a  dynamically 
adjusting  outline  of  the  window  with  it.  The  outline  shall  contract  if  the 
cursor  is  moved  toward  the  upper  left-hand  of  the  window  and  expand  if  the 
cursor  is  moved  away.  The  window  shall  remain  in  the  desired  size  as  soon 
as  the  trackball  button  is  clicked  a  second  time. 

(4)  Help  Box: 

This  box  is  a  small  square  icon  containing  a  question  mark.  It  will  normally 
be  positioned  in  the  right  comer  of  the  title  bar,  and  just  to  the  left  of  the 
iconify  box  if  present.  When  the  cursor  is  placed  over  the  help  box  and  the 
trackball  button  is  clicked  an  alphanumerical,  scrollable  window  will  be 
displayed  which  provides  access  to  help  for  the  application  window. 

(5)  Title  Bar: 

A  rectangular  bar  at  the  top  of  the  window  which  includes  the  title  of  the 
window  (and  the  window  number  if  multiple  copies  are  allowed),  and  may 
contain  amplifying  information  from  the  application  creating  the  window,  a 
close  box,  help  box  and  or/an  iconify  box.  If  a  window  title  is  bracketed  on 
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both  sides,  or  at  least  the  right  side  by  a  group  of  horizontal  lines  denoting 
a  drag  bar,  the  window  may  be  repositioned  on  the  screen  within  the 
confines  of  its  parent  windows. 


(6)  Scroll  Bars: 

Scroll  bars  are  used  to  change  the  view  of  the  contents  in  a  alphanumerical 
or  graphical  window  which  does  not  completely  fit  within  the  confines  of  the 
window  displayed.  A  vertical  scroll  bar  on  the  right-hand  side  of  the 
window  supports  paging  forward  and  backward  through  a  document  or  text 
while  a  horizontal  scroll  bar  on  the  bottom  edge  of  the  window  provides 
horizontal  movement. 

In  a  graphical  window  the  vertical  scroll  bar  supports  South-North  panning 
and  the  horizontal,  East-West  panning.  The  components  of  a  scroll  bar  are 
the  scroll  arrows  (located  at  the  end  of  each  scroll  bar),  a  white  box  in  a 
shaded  area  and  the  shaded  area.  Clicking  a  scroll  arrow  causes  the 
window  to  scroll  one  line  (or  column  as  appropriate)  in  the  direction  of  the 


42 


arrow  (in  a  graphics  window,  one-eight  of  the  viewable  page).  The  down 
arrow  shall  provide  scrolling  toward  the  end  of  the  file,  and  the  up  arrow 
toward  the  beginning  of  the  window  content.  Pressing  and  holding  on  an 
arrow  causes  continuous  scroll  until  the  button  is  released  or  the  end  of  the 
window  content  is  reached.  Clicking  in  the  area  on  either  side  of  the  scroll 
box  causes  the  box  to  move  up  or  one  page  in  the  direction  indicated.  The 
scroll  box  moves  in  the  direction  clicked  a  distance  proportional  to  the 
relative  movement  through  the  window  content.  If  the  user  places  the 
cjrsor  over  the  scroll  box  and  drags  the  cursor  along  the  shaded  bar,  the 
scroll  box  will  follow.  When  the  trackball  button  is  clicked  a  second  time, 
the  window  content  will  scroll  to  the  new  relative  position  of  the  scroll  box 
on  the  shaded  bar.  If  an  entire  scroll  bar  is  white,  then  the  entire  document 
or  graphic  area  is  completely  visible  in  its  direction. 

(7)  Push  Buttons: 

Shall  be  displayed  as  a  rectangular  object  with  rounded  comers  and  a  label 
in  the  center.  When  clicked,  they  shall  cause  the  application  to  execute  the 
captioned  command.  A  yellow  push-button  shall  indicate  a  recommended 
action;  all  other  push-button  shall  be  red. 

(8)  Check  Box: 

A  check  box  is  essentially  an  On/Off  switch.  On  when  the  small  square  box 
contains  a  check  mark  and  Off  when  the  box  is  empty.  Clicking  on  an  On 
check  box  shall  turn  it  Off  and  vice  versa. 

(9)  Radio  Buttons: 

„  May  be  used  when  selecting  from  multiple  options  where  only  one  can  be 
selected.  When  one  radio  button  is  selected,  the  previously  selected  button 
is  unselected.  Clicking  on  the  selected  button  leaves  it  selected.  An  empty 
circle  within  a  circle  icon  shall  denote  that  the  item  is  not  selected,  and  a 
black  filled  circle  within  a  circle  icon  shall  indicate  that  it  is  selected.  As 
shown  in  Figure  13,  radio  buttons  that  refer  to  similar  kinds  of  options 
should  be  grouped  in  sets  and  arranged  in  columns  or  rows.  A  label  that 
describes  the  choice  represented  by  the  radio  button  shall  be  displayed  to 
the  right  of  the  button. 

G  1.1. 1.2.1. 2. 2:  Window  Manipulation 

Through  the  use  of  the  trackball,  the  user  shall  be  able  to  perform  the 
following  manipulations  on  windows  which  include  a  drag  bar  and  a  resize 
box: 
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Functional  I/O  Window  Example 


Figure  13:  Standard  Support  Window  with  Check  Boxes,  Radio 
and  Push  Buttons 


(1)  Place: 

A  window  shall  be  placed  initially  at  a  position  and  size  set  by  the 
application.  The  user  will  then  be  able  to  move  the  window  to  a  desired 
position  and  change  its  size  as  described  below.  The  user  shall  be  allowed 
t  to  save  the  new  position  and  size  of  the  window. 

(2)  Move: 

Windows  may  be  moved  by  placing  the  cursor  on  the  drag  bar,  clicking  the 
trackball  button,  moving  the  cursor  to  the  desired  position,  and  then  clicking 
the  trackball  button  again.  When  the  button  is  initially  clicked  on  the  drag 
bar,  a  window  frame  shall  appear  and  move  with  the  cursor  until  the  next 
trackball  click.  When  the  trackball  button  is  clicked  the  second  time,  the 
window  shall  be  redrawn  in  its  new  position. 

(3)  Resize: 

A  resize  on  the  window  frame  shall  be  performed  by  placing  the  cursor  on  a 
comer  side  of  the  window  and  dragging.  The  procedure  to  resize  a  window 
using  the  resize  box  is  described  in  Resize  Box  (Goal  1  1 . 1.2. 1 .2. 1 ). 
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G  1. 1. 1.2. 1.2.3:  Window  States 


(1)  Input  Focus: 

The  "Input  Focus"  is  the  window  that  currently  receives  keyboard  and 
trackball  inputs.  By  default  the  focus  is  the  Root  Window  (Goal  1.1. 1.3.1). 
When  multiple  windows  are  displayed,  the  operator  shall  be  able  to 
designate  a  window  as  the  new  focus  by  clicking  into  it.  Once  designated  as 
input  focus,  the  window  shall  brought  to  the  front.  However  it  shall  not  be 
possible  to  place  other  windows  over  warning  windows  or  the  main  menu 
bar.  When  the  user  picks  an  option  and  a  window  is  opened,  the  focus  may 
shift  to  that  new  window. 

(2)  Active: 

A  window  is  active  when  the  associated  processing  continues  irrespective 
of  which  window  has  the  input  focus.  A  TacPlot  window  shall  always  be 
active  unless  closed  by  the  user.  The  clock  window  shall  always  be  active. 

(3)  Open: 

Multiple  windows  may  be  open  on  the  display  at  one  time.  The  input  focus 
window  is  active  until  the  function  is  completed,  the  operator  closes  the 
window,  changes  the  input  focus  to  another  window  or  activates  another 
window.  The  most  recently  activated  window  shall  come  to  the  front. 

(4)  Icon: 

An  active  window  which  does  not  require  user  interaction  for  extended 
periods  can  be  run  as  a  background  task.  To  serve  as  an  indicator  that  the 
,  application  is  running  and  to  provide  quick  access  when  changes  are 
required,  such  windows  may  be  iconified  using  the  Iconify  Box  as  described 
above. 

(5)  Close: 

When  a  window  is  closed,  it  is  removed  from  the  appropriate  display  and  all 
processing  relating  to  it  is  stopped. 

G  1.1. 1.2.1. 2.4:  Window  Formats 

All  windows  shall  adhere  to  one  of  the  following  formats: 

(1)  Plain  Box  Window: 

A  plain  black  border  box  with  no  close,  help,  iconify  or  resize  boxes  (used 
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for  the  clock  and  menus).  These  windows  are  application  controlled  and 
may  not  be  moved  by  the  user. 

(2)  Graphics  Application  Window: 

One  example  is  pictured  in  Figure  14.  It  includes  a  black  border  box  with  a 
graphics  application  menu  bar  just  below  the  title  bar  across  the  top  of  the 
window.  Graphics  windows  may  be  scrollable  as  appropriate  for  each 
individual  application.  The  bottom  left-hand  side  may  be  available  for 
application  icons  or  alphanumeric  remarks. 


Iraphics  Application  Name,  #  and  Notes 


□  □ 


Option  1  Option  2 


Option  n 


Item  1 
Item  2 

Item  i 

Item  n 


Standard  Support  Window 


New  Item 


C  Delete  3 


L  CancelJ  1  OK  J 


Available  for  Application  Use 


Figure  14  :  Graphics  Application  Window  and  Support  Window 


(3)  Scrollable  Document  Window: 

This  window  is  pictured  in  Figure  15.  It  shall  consist  of  a  black  border  box 
with  a  title  bar,  vertical  and  horizontal  scroll  bars  as  appropriate  and  an 
area  for  use  by  the  application  in  the  bottom  left-hand  comer.  The  window 
may  be  dragged  to  a  new  location,  resized  or  iconified  if  appropriate. 


(4)  Standard  Document  Window: 


This  window  is  pictured  in  Figure  20  and  shall  consist  of  the  same  features 
as  described  for  the  scrollable  document  window  except  for  the  scroll  bars. 
It  may  be  dragged,  resized  or  iconified  if  appropriate. 


Figure  15:  Document  Window  with  Scroll  Bars  and  Warning  Window 


(5)  Standard  Support  Window: 

This  is  a  fixed-location  window  which  requires  an  operator  response  to 
close.  It  has  a  double  border  and  normally  will  include  at  least  two  response 
buttons  ,  one  to  indicate  the  information  is  "OK"  as  currently  set  to  execute 
the  task  and  close  the  window,  and  a  second  to  "CANCEL"  the  window 
with  no  action  taken  even  if  the  user  has  entered  information.  Figure  13 
shows  an  example  of  a  Standard  Support  window  which  uses  Check  boxes, 
Radio  and  Push  Buttons.  Figure  14  shows  an  application  using  scroll  bars. 

(6)  Moveable  Support  Window: 

This  is  a  Standard  Support  Window  with  a  title  bar  and  drag  bar 
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functionality.  Figure  18  depicts  an  application  using  a  Moveable  Support 
Window. 

(7)  Warning  Windows: 

These  are  used  to  alert  the  user  to  an  abnormal  condition.  It  is  a  special 
version  of  the  standard  support  window  and  shall  at  least  include 
"Yes"/"No"  buttons  and  the  information  necessary  for  the  user  to  act 
accordingly. 


G  1.1. 1.2.1. 2.5.:  Menus 

A  menu  is  a  list  of  program  options  a  user  can  choose  from.  The  approach 
to  be  implemented  in  LCCDSWS  has  to  be  consistent  with  [Ref.  5,  p.25].  In 
LCCDSWS  at  least  the  Tactical  Display  Main  Menu  and  the  Tactical  Plot 
Menu  Manager  will  be  visible.  Primary  method  of  interaction  is  via  trackball. 

(1)  Main  Menu  Bar: 

In  the  second  row  of  the  Tactical  Display  Screen  (root  window)  is  a  one- 
line  bar  with  the  names  of  the  various  menu  options  as  illustrated  in  Figure 
16.  Normally,  each  menu  option  will  have  one  level  of  sub-menus 
displayable  as  a  pull-down  menu.  Menu  options  requiring  additional 
information  from  the  operator  to  execute  shall  normally  use  support 
windows  and  support  menus.  While  an  operator  is  interacting  with  the 
application  associated  with  a  menu  option,  that  menu  option  is  displayed  in 
reverse  video.  This  includes  the  occasions  when  a  sub-menu  is  displayed 
and  when  an  application  window  is  displayed  as  an  icon. 

I* 

(2)  Pull  Down  Menu: 

Implement  in  accordance  with  Reference  5,  Paragraph  3. 2. 1.1. 6.2. 

(3)  Application  Window  Menu  Bar: 

Implement  in  accordance  with  Reference  5,  Paragraph  3. 2. 1.1. 6.3. 

(4)  Support  Menu: 

Implement  in  accordance  with  Reference  5,  Paragraph  3. 2. 1.1. 6.4. 
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(5)  Menu  Formats  and  Features: 

Implement  in  accordance  with  Reference  5,  Paragraph  3. 2. 1.1. 6.5. 

Cl  1.1. 1.2. 1.2.6:  Window  Layout  Requirement 

The  window  layout  requirements  shall  be  consistent  with  the  layout 
requirements  for  NCCS-A  windows  as  described  in  Reference  5,  Paragraph 
3. 2. 1.1. 7.  This  includes  the  color  scheming. 

G  1.1. 1.2.1. 2.7:  Keyboard  Guidelines 

All  LCCDS  workstation  keyboards  shall  meet  the  requirements  for  NCCS- 
A  workstation  keyboards  as  described  in  Reference  5,  Paragraph  3.2. 1.1.8. 

G  1.1. 1.2. 1.2.8:  Help  Guidelines 

The  general  characteristics  for  the  "HELP"  function  in  LCCDS  shall  meet 
the  requirements  for  NCCS-A  as  described  in  Reference  5,  Paragraph 
3.2.1. 1.9. 

G  1.1. 1.2. 1.2.9:  General  Functionality  Guidelines 

General  functions  are  used  to  edit  graphics  and  text  in  multiple  windows. 
They  shall  be  consistent  with  Reference  5,  Paragraph  3.2.1.1.10. 


G  1.1. 1.3:  LCCDS  Windows 

This  following  shall  provide  concrete  examples  on  the  appearance  and 
interaction  features  of  some  of  the  basic  and  most  important  windows  to  be 
used  in  LCCDS.  It  shall  be  understood  that  these  requirements  are  not 
static,  rather  then  giving  a  concept  how  the  above  conventions  shall  be 
applied  to  the  windows  used.  It  is  expected  that  appearance  and 
interaction  techniques  for  this  p;oject  will  mature  as  experience  is  gained 
through  implementation  and  analysis  of  the  prototype.  The  main  purpose  of 
this  goal  is  to  provide  examples  how  MMI  features  for  LCCDS  shall  be 
constructed  from  the  building  elements  of  Goal  1.1. 1.2. 

G  1.1. 1.3.1:  The  Root  Window 

The  root  window  provides  a  fixed  background  for  the  Tactical  Display  and 
shall  cover  the  whole  screen.  It  is  not  moveable  or  sizeable  and  represents 
the  basic  workbench  for  the  user.  All  other  windows  will  appear  overlaid 
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over  the  root  window,  no  window  can  be  hidden  behind  the  root  window. 
However,  the  title  bar  and  the  main  menu  bar  of  the  root  window  shall 
always  be  visible.  The  root  window  is  pictured  in  Figure  16. 


Figure  16  :  LCCDS  R cot  Window 
G  1.1. 1.3.2:  The  Tactical  Plot  Window 


The  TacPlot  windows  will  be  a  Graphics  Application  Windows  as  described 
in  G  1.1. 1.2. 1.2. 4  and  used  for  graphics  I/O.  Their  possible  appearance  is 
shown  in  Figure  17.  The  figure  shows  some  examples  of  the  standard 
"NTDS  symbology  as  described  in  Goal  1.2. 1.1. 

G  1.1. 1.3.3:  The  Radar  and  Video  Select  Window 

This  window  in  figure  18  provides  Functional  I/O  for  selecting  a  radarvideo 
of  an  external  Radar-System.  It  is  built  from  a  Moveable  Support  Window 
together  with  Radio  and  Push  Buttons.  Note  that  it  can  be  iconified. 
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0  TacPlot  1,  Center  OS  53  45N  009  37W  f~7~|  |  | 

Option  1  Option  2  Option  3  ...  Option  n 

(/  /ED 
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OS:  045  -  17  Ball  Tab:  175  -  6  Range  16  — *. 

LE 

Figure  17  :  The  Tactical  Plot  Window 


G  1.1. 1.3.4:  The  Interface  Control  Window 

The  Interface  Control  Window  is  another  example  of  Functional  I/O.  It  is 
used  to  establish  communication  channels  to  external  subsystems.  It  is 
„  constructed  using  support  window,  dragbar,  iconify  box,  check  boxes  and 
push  buttons.  An  example  is  shown  in  Figure  19. 

G  1.1. 1.3.5:  New  Track  Establishment  Window 

Figure  20  depicts  an  example  of  an  Alphanumerical  I/O  window,  in  this  case 
the  manual  entry  of  a  new  track  into  the  system.  It  uses  a  standard 
document  window  and  push  buttons  to  confirm  or  cancel  the  entries  and 
provides  a  capability  to  display  and  enter  data  manually  in  support  of  Goal 
3.2.1.  The  window  could  be  used  as  result  of  a  grap'  ‘  VO  in  the  TacPlot  to 
manually  enter  a  new  track 
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Figure  18  :  Radar  and  Video  Select  Window 
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Figure  19  :  Example  Function  I/O  Window 
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Figure  20:  Standard  Document  (New  Track  Establishment)  Window 


G  1.2:  Tactical  Display  Features 

The  system  shall  provide  the  basic  features  of  a  standard  Navy  display 
console. 

The  Tactical  Display  shall  consist  of  a  tactical  plot  (TacPlot)  and 
■•associated  support  functions,  menus,  user  cues  and  alerts.  A  moving 
cursor  display  (Ball  Tab  or  Arrow  Pointer)  shall  be  available  to  allow  the 
user  to  designate  any  position  on  the  Tactical  Display  for  control, 
information  and/or  data  input  to  the  system. 

The  Cursor  symbol  shall  be  controllable  by  either  trackball  or  keyboard. 

The  Ball  Tab  shall  represent  the  Cursor  display  within  the  TacPlot  Graphics 
window  class.  Any  time  the  cursor  is  positioned  outside  the  boundary  of 
this  window  class  it  shall  be  represented  as  an  Arrow  Pointer. 

The  system  shall  provide  a  facility  for  fixed  and  variable  (operator  defined) 
function  keys.  The  function  keys  shall  provide  for  control,  data  entry  and 
interaction  with  the  software  system. 
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G  1.2.1:  Tactical  Plot  (TacPIot) 


The  tactical  plot  shall  display  data  denoting  tactical  information  pertaining 
to  an  area  of  surveillance. 

It  shall  be  capable  of  displaying  up  to  1000  symbols  (Tracks  and  Special 
Points). 

The  TacPIot  shall  be  based  on  a  X-Y  coordinate  system  with  origin  at 
Ownship  position. 

The  TacPIot  shall  provide  geographic  information  (latitude/longitude)  on  any 
selected  (hooked)  position. 

The  system  shall  provide  for  selection  of  range  scales. 

The  system  shall  allow  the  user  to  display  a  proportional  speed  leader  on 
each  track. 

The  system  shall  allow  the  user  to  filter  out  undesired  symbology. 

G  1.2.i.  1:  NTDS  Standard  Symbology 

TacPIot  functions  and  symbology  must  be  consistent  with  NTDS  definitions 
as  specified  in  References  7  and  13.  The  system  will  provide  the  following 
TacPIot  functions  and  associated  symbology  extracted  from  Enclosure  1  to 
Reference  4  (see  Appendix  A).  These  symbols  shall  be  kept  separate  from 
other  (system  control)  symbology  and  will  not  appear  outside  of  the 
window  defining  the  TacPIot: 

(1)  Ball  Tab:  Q 

The  Ball  Tab  is  a  moving  cursor  represented  by  a  one-quarter  inch  diameter 
circle  with  a  point  in  the  center.  The  Ball  Tab  shall  provide  direct  feedback 
to  the  operator  as  he  manipulates  the  trackball.  Movement  of  the  Ball  Tab 
within  the  TacPIot  shall  match  the  relative  speed  and  direction  of  any 
trackball  movement. 

There  shall  be  only  one  Ball  Tab  symbol  displayed  on  the  TacPIot  at  any 
time. 

(2)  Hook: 
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The  Hook  function  shall  identify  a  position  on  the  TacPlot  selected  for  some 
program  action.  As  shown  above  the  Hook  symbol  is  represented  as  a  one- 
half  inch  diameter  circle. 

The  Hook  function  shall  operate  in  conjunction  with  the  current  position  of 
the  Ball  Tab.  Any  point  within  the  TacPlot  may  be  identified  by  positioning 
the  Ball  Tab  and  actuating  the  Hook  function  by  clicking  on  a  trackball 
button. 

In  the  case  where  the  position  "hooked"  coincides  with  a  "hookable" 
symbol,  the  Hook  symbol  shall  appear  surrounding  that  symbol.  Only  one 
symbol  at  a  time  may  be  hooked.  The  following  symbols  shall  be 
"hookable": 

-  Tracks 

-  Ownship 

-  Waypoints 

-  Man  in  Water 

-  Navigation  Hazard 

-  Data  Link  Reference  Point 

-  Reference  Points 

-  Utility  Lines  and  Circles 

If  there  is  no  symbol  located  at  the  position  identified  by  the  Ball  Tab,  then 
that  position  shall  be  saved  for  further  program  action.  In  this  case  the 
'  Hook  symbol  shall  not  appear. 

(3)  Track  History  Point: 

The  functional  aspect  of  this  symbology  is  explained  in  Goal  4.2.5. 

(4)  Reference  Points: 

A  Reference  Point  function  shall  allow  the  user  to  display  up  to  20 
Reference  Point  symbols  at  any  hooked  position  on  the  TacPlot. 

(5)  Tracks: 

Tracks  are  symbolic  representations  of  remote  and  locally  generated  real 
world  objects  (air,  surface,  subsurface  contacts).  Each  track  is  composed  of 
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up  to  three  distinct  graphic  symbols.  The  most  basic  representation  of  a 
track  is  a  "dot"  representing  the  geographic  position  of  the  track. 
Additionally,  there  is  a  standard  (NTDS)  set  of  shapes,  used  for  track 
categorization/identification,  which  may  be  superimposed  over  the  dot  (see 
Figure  21).  The  third  component  is  the  Velocity  Leader  (see  subparagraph 
(14)  for  a  detailed  description). 

The  system  Tracking  function  shall  generate  and  display  all  Air,  Surface  and 
Subsurface  tracks  as  specified  in  Figure  21. 
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Figure  21  :  LCCDS  Track  Symbology 


(6)  Tentative  Track: 

New  tracks  generated  by  local  sensors  (radar)  shall  appear  on  the  TacPlot 
as  Tentative.  Once  a  valid  course  and  speed  is  established  for  the 
Tentative  track  the  symbology  will  change  to  reflect  the  correct  Track 
category  as  described  in  Figure  22. 

(7)  Ownship  position:  (J) 


Ownship  position  symbol  shall  be  located  in  the  center  of  the  TacPlot  by 
default.  Ownship  position  may  be  slewed  to  any  other  point  on  the  TacPlot 
while  maintaining  correct  spatial  relationship  with  all  other  TacPlot 
symbology.  There  shall  be  only  one  Ownship  position. 
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(8)  Navigation  Hazard: 


The  Navigation  Hazard  symbol  shall  be  available  to  the  user  for  marking 
the  geographic  position  of  known  navigational  hazards  on  the  TacPlot.  Up 
to  50  may  be  displayed  at  once. 

(9)  Man  in  Water: 


This  symbol  shall  be  available  to  the  user  for  marking  the  geographic 
position  of  a  man  in  the  water.  Up  to  7  may  be  displayed  on  the  TacPlot  at 
once.  It  can  be  entered  onto  the  TacPlot  at  an  position  using  the  Hook 
function.  If  no  position  is  hooked,  then  the  Main  in  Water  symbol  is  entered 
at  the  current  Ownship  position. 


(10)  Waypoint: 


Functions  and  program  action  associated  with  this  symbol  is  described  in 
section  Goal  4. 1.2.1. 


(11)  Data  Link  Reference  Point: 


The  DLRP  represents  a  fixed  geographic  reference  position  common  to  all 
Link  1 1  participating  units.  There  shall  be  only  one  DLRP  symbol  active  in 
the  system  at  one  time. 


'(12)  Formation  Center: 


The  Formation  Center  is  a  moving  geographic  position  representing  the 
center  of  a  group  of  ships  steaming  in  formation.  This  position  shall  have 
the  formation  course  and  speed  associated  with  it.  There  may  be  up  to  two 
Formation  Center  symbols  active  in  the  system  at  one  time. 


(13)  Position  and  Intended  Movement  (PIM): 

The  PIM  function  provides  time-speed-distance  information  for  progress 
along  a  selected  steaming  route  associated  with  Ownship  or  Formation 
Centers. 
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PIM  can  be  viewed  as  Ownship  or  formation  planned  position  based  on  a 
pre-computed  base  course  and  speed  to  arrive  at  destination  at  the 
required  time.  The  PIM  function  associated  with  Ownship,  and/or 
Formation  Center,  shall  provide  the  following  navigational  information 
based  on  destination  time  and  place  and  associated  base  course  and  speed: 

display  the  PIM  symbol  at  the  planned  position  along  the  steaming 
route  based  on  current  or  user  selected  time. 

PIM  shall  maintain  a  running  calculation  of  distance  and  time 
ahead/behind  plan  based  on  current  geographic  position. 

provide  recommended  course  and  speed  for  Ownship  in  order  to  regain 
PIM  position. 

(14)  Velocity  Leaders: 

The  Velocity  Leader  is  a  vector  (line)  of  variable  length  and  direction 
associated  with  each  track  displayed  on  the  TacPlot.  Vector  origin  is  the 
center  (dot)  of  the  track  symbol  with  direction  representing  track  course 
and  length  varying  proportionally  with  track  speed.  Velocity  leaders  shall 
be  displayed  with  all  active  track  symbols  on  the  TacPlot  unless  the  user 
chooses  to  Filter  them  out.  Figure  22  provides  a  depiction  of  a  Velocity 
Leader  associated  with  a  Track  classified  as  Hostile  Air. 


Figure  22  :  Velocity  Leader 


Velocity  Leaders  shall  be  displayed  by  default  when  course  and  speed 
information  for  any  track  becomes  available.  The  user  shall  have  the 
capability  to  toggle  Velocity  Leaders  on/off  for  all  tracks,  specified 
categories,  or  individually  using  the  hook  function. 

The  default  length  value  for  Velocity  Leaders  shall  be  based  on  12  minutes 
of  track  travel  at  current  track  speed.  This  length  value  shall  be  operator 
variable  between  3  and  90  minutes. 
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G  1.2. 1.2:  Track  Category  Select  Function 

This  function  shall  provide  the  user  with  a  selection  matrix  of  possible  track 
categories  and  symbolic  representations.  The  categories  are  outlined  in 
Figure  21.  In  addition  to  providing  the  category  select  feature,  this  matrix 
also  provides  selection  of  various  symbolic  representations  for  any  category 
or  individual  track.  The  options  available  follow: 

(1)  Normal: 

The  graphic  shape  representing  the  track  category  (see  Figure  21)  of  any  or 
all  associated  tracks  is  displayed  in  normal  size  as  specified  by  NTDS 
standards  [Ref.  131. 

(2)  Enlarged: 

The  graphic  shape  representing  the  track  category  (see  Figure  21)  of  any  or 
all  associated  tracks  is  displayed  in  twice  normal  (enlarged)  size  as 
specified  by  NTDS  standards  [Ref.  13]. 

(3)  Suppressed: 

The  graphic  shape  representing  the  track  category  (see  Figure  21)  of  any  or 
all  associated  tracks  is  not  displayed.  Suppressed  tracks  are  represented 
by  a  "dot"  only,  located  at  current  geographic  position. 

G  1.2. 1.3:  TacPlot  Display  Control  Functions 

The  following  display  control  functions  have  been  adapted  for  LCCDSWS 
from  existing  CDS  and  C3  systems  [Ref.  7,  Ref.  15] 

-(1)  Hook: 

The  Hook  function  identifies  the  position  of  a  symbol  or  arbitrary  point  on 
the  TacPlot  for  use  by  an  active  function,  or  for  subsequent  use  by  a 
function.  Only  one  symbol  or  point  on  the  TacPlot  can  be  hooked  at  any 
time. 

(2)  Recenter  On  Ownship: 

The  Recenter  On  Ownship  function  reorients  the  TacPlot  with  the  Ownship 
symbol  positioned  in  the  center  of  the  window.  All  displayed  Tracks  and 
Special  Points  shall  move  to  retain  correct  spatial  relationships  relative  to 
Ownship  and  TacPlot  center. 

(3)  Recenter  On  Lat/Long: 

The  Recenter  On  Lat/Long  function  reorients  the  TacPlot,  centering  the 
window  at  a  desired  geographic  position.  All  displayed  Tracks  and  Special 
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Points  shall  move  to  retain  correct  spatial  relationships  relative  to  Ownship 
and  TacPlot  center. 

(4)  Recenter  On  Hook: 

The  Recenter  On  Hook  function  reorients  the  TacPlot,  centering  the  window 
at  the  current  hooked  position.  All  displayed  Tracks  and  Special  Points 
shall  move  to  retain  correct  spatial  relationships  relative  to  Ownship  and 
TacPlot  center. 

(5)  Read  Lat/Long: 

The  Read  Lat/Long  function  displays  the  geographic  latitude  and  longitude 
coordinates  of  any  hooked  position  (symbol  or  arbitrary  point)  on  the 
TacPlot. 

(6)  Display  Lat/Long: 

The  Display  Lat/Long  function  displays  a  single  Track  History  point  at  the 
geographic  position  associated  with  a  set  of  latitude  and  longitude 
coordinates  entered  by  the  user. 

(7)  Amplify: 

The  Amplify  function  shall  display  alphanumeric  amplifying  information 
either  selectively  for  any  hooked  symbol,  or  generally  for  all  displayed 
symbols. 

(8)  Increase/Decrease  Scale: 

TacPlot  Range  Scale  shall  be  provided  as  a  information  window  within  the 
TACPlot  at  all  times.  The  unit  of  measure  shall  be  the  nautical  mile  (NM). 
'The  Range  Scale  shall  be  an  integer  and  a  member  of  the  following  set  of 
values: 

1,  2,  4,  8,  16,  32,  64,  128,  256,  512,  1024 

The  scale  selected  is  equal  to  the  radius  of  the  largest  enscribable  circle 
contained  within  the  TacPlot.  See  Figure  23  for  a  graphic  representation 
using  16  nm  as  an  example. 
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Figure  23  :  The  Tactical  Plot  Range  Scale 


(9)  Destroy  Symbol: 

The  Destroy  Symbol  function  removes  selected  (hooked)  symbols  from  the 
TacPlot  and  Tactical  Database  on  an  item-by-item  basis.  Cleared  symbols 
are  not  removed  from  the  Tactical  Database  and  may  be  recalled 
'  (redisplayed)  if  desired  using  the  Recall  function. 

(10)  Clear  Symbol: 

The  Clear  Symbol  function  removes  selected  (hooked)  symbols  from  the 
TacPlot  on  an  item-by-item  basis.  Cleared  symbols  are  not  removed  from 
the  Tactical  Database  and  may  be  recalled  (redisplayed)  if  desired  using 
the  Recall  function. 
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(11)  Recall: 


The  Recall  function  redisplays  previously  cleared  symbology.  The  user 
shall  be  given  a  choice  of  recalling  all,  or  some  specified  category  of, 
symbols. 

(12)  Display  Link: 

This  function  shall  display  all  Link  1 1  remote  tracks  upon  user  demand. 

(13)  Assign  Track  Number: 

The  system  shall  automatically  assign  track  numbers  to  all  locally 
generated  tracks  based  upon  a  user  designated  set  of  integers.  Valid  track 
numbers  must  be  four  digit  integers  in  the  range  of  0200-7776  to  ensure 
compatibility  with  Link  1 1  remote  tracks. 

(14)  Ownship  to  Position: 

This  function  provides  range  and  bearing  (true  or  relative)  from  Ownship  to 
any  arbitrary  hooked  position  on  the  TacPlot.  The  range  and  bearing  values 
will  update  continuously  as  Ownship  moves  in  relation  to  the  hooked 
position. 

(15)  Ownship  to  Ball  Tab: 

This  function  provides  range  and  bearing  (true  or  relative)  from  Ownship  to 
current  Ball  Tab  position  on  the  TacPlot.  The  range  and  bearing  values  will 
update  continuously  as  Ownship  moves  in  relation  to  the  Ball  Tab  position 
and  as  the  user  changes  the  Ball  Tab  position.  The  Range  and  bearing 
values  shall  "float"  alongside  the  Ball  Tab  symbol  as  it  moves  at  all  times 
„  while  this  function  is  active. 

G  1.2.1.4:  TacPlot  Graphic  Tools 

Availability  of  utility  lines,  circles  and  other  graphic  objects  is  necessary  for 
the  user  to  manage  the  tactical  picture  and  enhance  tactical  decision¬ 
making. 

Graphics  Tools  shall  be  considered  a  subset  of  Special  Points  managed  and 
maintained  in  the  Tactical  Database.  They  shall  be  defined  by  lat/long 
position  and  dimension  attributes.  These  graphics  shall  appear  as 
background  shapes  on  the  TacPlot  and  will  not  obscure  Tracks  and  other 
Special  Points  as  defined  in  Goal  1 .2. 1 . 1 . 

Graphic  Tools  may  be  filled  or  unfilled,  have  variable  width  borders  and 
have  text  associated  with  each  object. 
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As  a  minimum,  available  border  styles  shall  support  creation  of  solid, 
dotted  and  dashed  lines. 

The  following  Graphic  Tools  shall  be  available  for  use  on  the  TacPlot: 

(1)  Lines: 

Lines  may  originate  at  any  hooked  position,  symbol  or  designated  lat/long 
on  the  TacPlot.  The  Line  function  displays  a  straight  line  originating  from 
the  preceding  hooked  position  to  the  current  position  of  the  Ball  Tab, 
moving  with  the  Ball  Tab  as  the  user  moves  the  trackball. 

(2)  Circle: 

Circles  may  originate  at  any  hooked  position,  symbol  or  designated  lat/long 
on  the  TacPlot.  The  Circle  function  displays  a  circle  centered  on  the 
preceding  hooked  position  with  radius  equal  to  the  distance  between  origin 
and  current  position  of  the  Ball  Tab,  varying  with  the  Ball  Tab  as  the  user 
moves  the  trackball. 

(3)  Range  Circle: 

This  function  displays  a  circle  whose  center  is  the  Ball  Tab  with  fixed,  user 
entered,  radius.  The  range  circle  will  float  in  conjunction  with  Ball  Tab 
movement  and  may  be  fixed  to  any  desired  point  on  the  TacPlot  using  the 
Mark  function. 

(4)  Expanding  Circle: 

This  function  depicts  a  circular  area  of  probability  of  a  track/target 
associated  with  a  time  and  position  on  the  TacPlot.  From  origin,  a  circle 
„  expands  at  a  rate  determined  by  a  user  entered  speed  estimate  for  the  track. 

(5)  Moving  Circle: 

This  function  generates  a  circular  area  of  fixed  radius  which  moves  across 
the  TacPlot  from  its  origin  (hooked  position)  with  a  user  entered  course  and 
speed. 

(6)  Radar  Horizon: 

This  function  depicts  the  estimated  line-of-sight  range  of  the  platform’s 
radar  based  on  user  entered  values  of  height  above  waterline,  type  of  radar, 
operating  mode  and  environmental  (weather)  effects.  While  this  function  is 
active  a  viivL  depicting  this  radar  range  estimate  shall  be  displayed  with 
Ownship  in  its  center. 
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(7)  Ellipse: 

Ellipses  may  originate  at  any  hooked  position,  symbol  or  designated 
lat/long  on  the  TacPlot.  The  Ellipse  function  displays  an  ellipse  centered 
on  the  desired  position  with  user  entered  values  for  major  and  minor  axes. 
This  function  may  also  operate  in  a  "rubber  band"  fashion  where  the  shape 
is  stretched  and  sized  based  on  Ball  Tab  movement  in  relation  to  a 
previously  hooked  position.  The  Ellipse  may  be  slewed  to  any  position  on 
the  TacPlot  and  rotated  up  to  180  degrees  before  being  fixed  using  the  Mark 
function. 

(8)  Rectangle: 

Rectangles  may  originate  at  any  hooked  position,  symbol  or  designated 
lat/long  on  the  TacPlot.  The  Rectangle  function  displays  a  square  or 
rectangular  shape  centered  on  the  desired  position  with  user  entered 
length/width  values.  If  only  one  value  is  entered,  a  square  will  be 
generated.  This  function  may  also  operate  in  a  "rubber  band"  fashion  where 
the  shape  is  stretched  and  sized  based  on  Ball  Tab  movement  in  relation  to 
a  previously  hooked  position.  The  Rectangle  may  be  slewed  to  any  position 
on  the  TacPlot  and  rotated  up  to  180  degrees  before  being  fixed  using  the 
Mark  function. 

(9)  Arc: 

Arcs  may  originate  at  any  hooked  position,  symbol  or  designated  lat/long  on 
the  TacPlot.  This  function  shall  operate  in  a  "rubber  band"  fashion  where 
the  shape  is  stretched  and  sized  based  on  Ball  Tab  movement  in  relation  to 
a  previously  hooked  position.  The  Arc  may  be  slewed  to  any  position  on  the 
TacPlot  and  rotated  up  to  180  degrees  before  being  fixed  using  the  Mark 
function. 

(10)  Mark: 

The  Mark  function  fixes  a  previously  drawn  graphic  object  to  its  current 
position  on  the  TacPlot. 

(11)  Save: 

The  Save  function  operates  on  user  generated  graphic  objects  which  exist 
on  the  TacPlot  allowing  them  to  be  saved  in  the  Tactical  Database  as  user 
defined  instantiations  of  the  USERDEFINED  (see  Goal  3.3)  class  of 
database  objects. 
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G  1.2. 1.5:  Map  Display 


The  LCCDSWS  shall  provide  the  capability  to  superimpose  shoreline  maps 
on  the  selected  TacPlot  display. 

G  1.2. 1.5.1:  Map  Database 

The  user  shall  have  access  to  available  World  Vector  Shoreline  (WVS)  or 
DMA  Digital  Terrain  Elevation  (DTED)  map  data  stored  in  a  separate 
database. 

G  1.2.1. 5.2:  Map  Functions 
G  1.2. 1.5.2. 1:  Map  Display  Function 

The  default  map  displayed  shall  be  that  part  of  the  shoreline  visible  based 
on  current  TacPlot  range  scale  and  geographic  position  (lat/long)  of  the 
TacPlot  display  center.  Appropriate  user  cues  and  alerts  shall  be 
generated,  via  Function  I/O  windows,  when  the  Map  Display  function  is 
initiated  and  the  nearest  shoreline  is  either  off  scale  or  completely  out  of 
range. 

G  1.2.1.5.2.2:  Map  Select  Function 

Any  section  of  shoreline  may  be  arbitrarily  selected  for  display  by  entering 
a  lat/long  into  an  appropriate  Function  I/O  window.  Any  shoreline  within 
maximum  displayable  range  centered  around  this  point  shall  be  displayed. 

Pre-defined  shoreline  segments,  ports,  harbors,  chokepoints  etc,  shall  be 
user  selectable,  via  menu  choice,  for  display  on  a  specified  TacPlot 
'  Additionally,  the  user  shall  be  capable  of  defining  and  storing  associated 
navigational,  tactical  and  other  information  associated  with  these  pre¬ 
defined  maps. 

G  1. 2.1. 5.2.3:  Bottom  Contours 

Bottom  contour  lines  necessary  for  coastal  navigation  and  operations  shall 
be  available  for  display  in  conjunction  with  shoreline  maps. 

G  1.2. 1.5. 2. 4:  Display  Grid  Lines 

Latitude  and  longitude  grid  lines  are  user  selectable  anytime  regardless  of 
proximity  of  landmasses  or  displayed  maps.  They  shall  be  toggled  on/off, 
displayed  at  either  full  or  half  degree  increments,  and  be  represented  by 
solid,  dotted  or  dashed  lines  as  selected  by  the  user. 
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G  1.2.1.5.2.4.1:  Coordinate  Labels 


Latitude  and  longitude  values  associated  with  each  grid  line  shall  be 
selectable  (on/off)  by  the  user.  When  selected  on,  latitude  labels  shall 
appear  on  either  side,  longitude  labels  across  the  top  and  bottom  of  the 
TacPlot,  superimposed  over  the  appropriate  grid  line. 

G  1.2.1. 5.2.5:  Landmass  Fill 

The  landmass  side  of  any  displayed  shoreline  shall  be  fillable  using  color  or 
fill  patterns  as  desired. 

G  1.2.1.5.2.6:  Refresh 

The  displayed  segment  of  a  shoreline  map  shall  be  automatically  updated 
(refreshed)  as  the  TacPlot  tactical  picture  changes.  Map  refresh  shall  be 
necessary  for  the  following  conditions: 

-  user  demand  (via  a  Map  Refresh  function) 

-  Ownship  position  change 

-  Change  of  TacPlot  range  scale 

-  Use  of  any  of  the  TacPlot  Recentering  functions 

G  1.2.L5.2.6.1:  Map  Refresh 

This  function  is  available  from  the  Map  menu  as  a  single  action  switch 
which  updates  the  currently  displayed  shoreline  map  segment  or  redisplays 
,  a  previously  cleared  shoreline  map. 

G  1.2.1.5.2.7:  Map  Clear 

This  function  allows  the  user  to  suspend  display  of  the  map.  The  cleared 
map  may  be  updated  and  redisplayed  by  use  of  the  Map  Refresh  function. 

G  1.2. 1.6:  Sensor  Selection 

The  TacPlot  shall  maintain  an  indication  of  the  sensor  selected  for  each 
TacPlot  Window  as  applicable.  An  example  for  a  sensor  selection  window 
is  provided  by  Goal  1 . 1 . 1 .3.3  and  shall  be  available  for  each  TacPlot  window. 
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(i  1.3:  Display  Doctrine 

The  system  shall  provide,  via  a  Display  Doctrine,  the  capability  for  user 
defined  conditional  statements,  in  IF-THEN  form,  which  control  data 
filtering  and  specify  presentation  parameters  for  displayed  data.  These 
conditional  statements  are  the  building  blocks  for  the  Display  Doctrine. 

G  1.3.1:  Display  Doctrine  Scope 

There  shall  be  one  Display  Doctrine  associated  with  each  instantiation  of 
the  Graphics  window  class.  In  other  words,  each  active  TacPlot  has  its 
own  independent  Display  Doctrine.  The  Display  Doctrine  for  one  TacPlot 
instantiation  shall  have  the  capability  to  be  copied  directly  into  the  Display 
Doctrine  of  any  other  active  TacPlot  windows. 

The  user  shall  have  the  capability  to  define  a  set  of  conditions  which,  if  met, 
will  cause  some  display  function,  or  set  of  functions,  to  effect  the  Tactical 
Display  in  some  manner  to  tailor  the  displayed  tactical  information  as 
necessary  for  the  mission  and  to  alert  the  user  when  any  specified  event  or 
situation  occurs. 

G  1.3.2:  Display  Doctrine  Structure 

The  Display  Doctrine  shall  be  comprised  of  a  set  of  one  or  more  IF-THEN 
conditional  statements.  Each  Display  Doctrine  statement  shall  consist  of 
two  clauses;  an  IF  clause  specifying  certain  conditions  to  be  met,  and  an 
associated  THEN  clause  specifying  the  appropriate  action  to  be  taken. 
Figure  24  depicts  the  general  syntax  for  a  single  Display  Doctrine  IF- 
THEN  statement.. 

i* 

These  statements  shall  be  simple  and  easily  defined  using  window-based 
templates  and  forms  with  appropriate  information  fields.  These  fields  shall 
have  appropriate  choices  tied  to  pop-up  menus,  tableaus  and  lists  as 
necessary  to  aid  user  selection. 

The  choice  of  appropriate  IF  conditions  and  associated  THEN  operations  on 
the  data  presentation  shall  be  context  sensitive.  In  other  words,  the  menu 
choices  offered  must  correspond  to  the  data  attributes  of  the  object  (i.e.  a 
TacPlot  window,  track,  or  category  of  tracks)  which  the  Display  Doctrine 
statement  must  operate  upon. 
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Figure  24  :  Display  Doctrine  Syntactic  Structure. 


G  1.3.2. 1:  The  IF  Clause 

The  IF  clause  shall  specify  the  condition,  or  set  of  conditions,  to  be  met. 
The  IF  clause  of  any  statement  shall  allow  up  to  at  least  12  qualifying 
conditions,  connected  together  using  either  the  AND  or  the  OR  logical 
operators. 

G  1.3.2. 1.1:  Logical  Connectives 

The  logical  connectives  AND  and  OR  shall  be  used  to  link  the  qualifying 
conditions  (if  more  than  one)  of  the  IF  clause.  For  the  purposes  of  clarity 
and  simplicity  of  each  individual  IF-THEN  statement,  the  AND  and  OR 
connectives  shall  be  considered  mutually  exclusive  logical  operators.  When 
the  user  indicates  more  than  one  qualifying  condition  in  the  IF  clause  he 
must  choose  one  or  the  other.  This  operator  shall  connect  all  qualifying 
conditions  in  the  IF  clause  for  that  statement. 

G  1.3.2. 1.2:  IF  Clause  Qualifying  Conditions 

The  qualifying  conditions  shall  be  specified  using  boolean  expressions. 
These  expressions  are  defined  as  comparisons  between  a  specified 
attribute  of  some  object  and  a  threshold  value  associated  with  that 
attribute. 

The  result  of  any  comparison  shall  assign  a  boolean  value  (TRUE/FALSE) 
to  the  associated  qualifying  condition.  The  logical  connectives  AND  and 
OR  make  the  overall  determination  of  TRUE  or  FALSE  for  the  IF  clause  as 
follows: 

(1)  AND  Operator.  If  any  (one  or  more)  qualifying  conditions  in  an  IF 
clause  resolves  to  FALSE  then  the  IF  clause  as  a  whole  is  FALSE  and  the 
corresponding  THEN  clause  is  not  executed.  All  qualifying  conditions 
comprising  the  IF  clause  must  resolve  to  TRUE  in  order  for  the  THEN 
clause  to  be  invoked. 
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(2)  OR  Operator.  If  any  qualifying  condition  in  an  IF  clause,  containing 
one  or  more  qualifying  conditions,  resolves  to  TRUE  then  the  IF  clause  as  a 
whole  is  TRUE  and  the  corresponding  THEN  clause  is  executed.  Any  one 
qualifying  condition  comprising  the  IF  clause  must  resolve  to  true  in  order 
for  the  THEN  clause  to  be  invoked. 

The  following  boolean  operators  (comparators)  shall  be  available  for  use  in 
defining  the  comparisons: 

-  equal (=) 

-  not  equal  (<>) 

-  less  than  (<) 

-  greater  than  (>) 

-  less  than  or  equal  (<=) 

-  greater  than  or  equal  (>=). 

Cl  1.3.2. 1.3:  Boolean  Expression  List 

The  IF  clause  shall  consist  of  a  boolean  expression  list  containing  one  or 
more  expressions  linked  using  one  of  the  logical  connectives.  The  syntax 
required  for  construction  of  any  boolean  expression  is  outlined  in  Figure  25. 
The  system  shall  provide  the  user  with  a  "fill-in-the-bla»ik”  style  template 
supporting  at  least  12  expressions.  Along  with  the  templates  shall  be 
associated  support  windows  which  provide  the  user  with  an  appropriate 
range  of  choices  for  each  information  input  field.  Input  fields  shall  be  filled 
by  the  user  via  alphanumeric  input  and/or  "checkbox"  style  menu 
selections.  Each  information  field  must  be  context  sensitive  in  that  it  has 
the  capability  of  alerting  the  user  when  an  invalid  or  inappropriate  entry  has 
been  made.  Additionally,  the  system  shall  evaluate  each  completed 
expression,  as  a  whole,  to  ensure  appropriate  semantic  content  (to  protect 
against  syntactically  correct  nonsensical  operations). 

G  1.3.2. 1.4:  Expression  Attributes  and  Threshold  Values 

Each  boolean  expression  shall  evaluate  to  TRUE  or  FALSE  based  on  the 
logical  comparison  of  the  current  value  of  a  specified  Attribute  and  the 
specified  Threshold  Value  for  that  Attribute.  These  Attributes  appropriate 
for  selection,  and  range  of  values  associated  with  each,  shall  be  provided  to 
the  user  to  assist  construction  of  semantically  correct  Display  Doctrine 
function  definitions. 
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ATTRIBUTE 

THRESHOLD 

VALUE 


Figure  25  :  Boolean  Expression  Structure 

C,  1.3.2. 2:  The  THEN  Clause 

The  THEN  clause  shall  specify  the  operation  to  be  invoked  when  (if)  the 
condition,  or  set  of  conditions,  is  met. 

These  operations  should  include,  but  not  be  limited  to,  the  following  types 
of  display  related  activity:  blinking,  enlarging  or  otherwise  enhancing 
tactical  symbology,  displaying  pop-up  cues,  messages,  alerts,  tableaus  or 
on-line  checklists. 

(i  1.3.2. 2.1:  THEN  Operations  Definition 

The  THEN  clause  specifies  the  operations  which  will  act  on  the  TacPlot 
,  graphics  display  whenever  the  associated  IF  conditions  are  fulfilled.  There 
shall  be  two  types  of  operation,  categorized  as  default  and  user-defined , 
available  for  use  by  any  Display  Doctrine  statement. 

(»  1.3. 2. 2. 1.1:  Default  Operations 

There  are  certain  display  characteristics  which  are  part  of  the  basic  CDS 
and  already  available  through  the  Track  Category  Select  function  (Goal 
1.2. 1.3).  These  characteristics,  therefore  by  default,  are  available  for  use 
by  the  Display  Doctrine  IF-THEN  statements. 

The  following  default  operations  shall  be  available  for  use  as  Display 
Doctrine  operations: 
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-  Normal 

-  Enlarged 

-  Suppressed 

-  Toggle  Velocity  Leader  On/Off 

-  Extend  Velocity  Leader 

G  1.3.2. 2. 1.2:  User-Defined  Operations 

In  addition  to  the  Defaul'  operations  available  for  use  are  any  pre-defined 
operations  specified  by  the  user.  Any  appropriate  user-defined  operations 
may  be  added  to  the  current  menu/list  of  available  THEN  operations  for  any 
given  Display  Doctrine  statement. 

User-defined  operations  shall  be  constructed  separately  from,  but  in  a 
similar  manner  as,  the  Display  Doctrine  statements.  The  system  shall 
provide  the  user  with  "fill-in-the-blank"  style  templates  to  quickly  and 
easily  guide  the  user  through  the  necessary  choices  for  building  various 
sorts  of  display  operations.  Along  with  the  templates  shall  be  associated 
support  windows  which  provide  the  user  with  an  appropriate  range  of 
choices  for  each  information  input  field.  Input  fields  shall  be  filled  by  the 
user  via  alphanumeric  input  and/or  "checkbox"  style  menu  selections.  Each 
information  field  must  be  context  sensitive  in  that  it  has  the  capability  of 
alerting  the  user  when  an  invalid  or  inappropriate  entry  has  been  made. 
See  Figure  26  for  a  graphic  example. 

The  following  list  provides  some  examples  of  user-defined  operations 
which  should  be  available  for  use  as  Display  Doctrine  operations: 

blinking  symbology. 

opening  user  defined  alphanumeric  or  function  windows  with  cues, 
alerts  and  information  tailored  to  specified  tactical  conditions  and 
situations. 

changing  or  intensifying  colors,  using  inverse  video, 
displaying  user  defined  graphic  objects  or  icons. 

G  1.3.3:  Display  Doctrine  Modification 

The  user  shall  have  the  capability  to  modify  any  Display  Doctrine 
statement  in  order  to  change  either  the  Boolean  Expression  List  or  the 
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Operation  List.  Statements  may  be  added  or  deleted  to  any  Display 
Doctrine  as  desired  by  the  user. 

G  1.3.4:  Display  Doctrine  Consistency  Checking 

The  system  shall  ensure  that  all  statements  entered  into  the  Display 
Doctrine  are  consistent  with  statements  already  existing.  The  Display 
Doctrine  associated  with  each  instantiation  of  a  Graphics  Window 
(TacPlot)  can  be  viewed  as  a  set  of  user  requirements  for  that  window. 
The  system  shall  be  capable  of  determining  that  a  newly  entered  statement 
conflicts  with  some  previous  one.  In  such  cases  the  system  shall  alert  the 
user.  Under  no  circumstance  shall  the  system  allow  conflicted  statements 
to  go  unresolved. 

G  1.3.5:  Display  Doctrine  Applications 

The  Display  Doctrine  shall,  as  a  minimum,  apply  to  and  operate  on  the 
following  types  of  displayed  information: 

-  all  Tracks  qualifying  for  display 

-  all  tracks  of  a  particular  Track  Category  qualifying  for  display 

-  any  single  Track  or  Special  Point  identified  using  the  Hook  function. 


72 


Figure  26  :  Display  Doctrine  Statement  Construction 


2.  System  Control  Function 


a.  Preface 

The  system  control  function  is  neither  requested  by  the  customer  nor 
described  in  one  of  the  increments.  However,  the  study  of  an  existing  CDS  [Ref.  7] 
made  it  clear,  that  a  collection  of  functions  to  control,  monitor  and  initialize  the  system 
will  be  necessary. 

b.  Goals 

G  2:  System  Control  Function 

The  system  has  to  control,  initialize  and  monitor  the  LCCDS  hardware  and 
software  configurations.  We  refer  to  this  function  as  the  System  Control 
Function. 

The  System  Control  Function  shall  be  supported  by  a  set  of  menu  choices, 
dialogs,  cues  and  tableaus,  which  allow  the  user  to  initialize,  manage  the 
I/O  configuration  with  external  system  and  select  display  characteristics 
such  as  color,  window  positions. 


G2.1:  Initialization: 

Upon  initialization  the  system  shall  require  entry  of  the  following 
navigational  parameters  : 

G  2.1.1:  Ownship  Position 

Ownship  position  (automatic  entry  from  Navigational  System  when 
enabled,  otherwise  manual). 

G  2.1.2:  Greenwich  Mean  Time 

Greenwich  Mean  Time  (automatic  entry  from  Navigational  System  when 
enabled,  otherwise  manual). 

G  2.1.3:  CPA  Parameters 

CPA  Parameters  (manually): 

-  Close  CPA  Range:  200  -  9,999  yards, 
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-  Close  CPA  Time  :  5  -  99  minutes, 

-  Collision  CPA  Range:  1  -  199  yards, 

-  Collision  CPA  Time:  5-99  minutes. 

The  system  shall  allow  the  user  to  save  the  CPA  parameters  for  future 
use. 

G  2,1.4:  Data  Link  Reference  Point  (DLRP) 

Enter  the  DLRP  (manually);  if  no  DLRP  is  entered  it  shall  be  set  to 
ownship  initial  position,  thereafter  DLRP  shall  be  updated  by  manual 
entries. 

G  2.1.5:  Julian  Date 

Enter  the  Julian  Date  (manually);  it  will  be  used  for  user  information  only. 

G  2.1.6:  Initial  Values 

If  the  navigational  system  is  ready  and  operational  upon  initialization  the 
I/O  channel  shall  be  enabled  by  preset,  otherwise  disabled. 

In  case  the  Navigational  System  is  enabled,  in  addition  to  ownship  position 
and  GMT,  ownship  course  and  speed  values  shall  be  accepted  from  the 
Navigational  System.  Otherwise  course  and  speed  shall  be  set  to  0, 
thereafter  course  and  speed  shall  be  updated  by  manual  and  automatic 
updates. 

If  the  navigational  parameters  are  not  entered  within  5  minutes  of 
initialization,  the  sy?**m  shall  notify  the  user. 

i* 


G  2.2:  Configuration  Control 

The  system  shall  provide  the  user  with  a  choice  of  available  input/output 
channels  for  external  systems  (i.e.  Radar,  Link  1 1,  Navigation). 

G  2.2.1:  I/O  Channels 

The  system  shali  provide  the  capability  for  identifying  up  to  20  separate  I/O 
channels.  The  user  will  have  control  over  the  channel  configuration  via  the 
MM1.  An  example  for  such  a  control  mechanism  (Interface  Control 
Window)  is  described  in  Goal  1.1. 1.3.4. 
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G  2.3:  Configuration  Monitoring 

The  system  shall  provide  the  capability  to  monitor  hardware  and  software 
configurations  for  both  LCCDS  and  external  systems. 

G  2.3.1:  LCCDS  System  Status. 

The  system  shall  provide  for  error  detection  and  notification.  Changes  to  the 
system  status  not  initiated  by  the  user  shall  result  in  display  of  an 
appropriate  warning  window  and  automatic  update  of  the  System  Status 
Tableau  (Goal  4.6.2.10). 

G  2.3.2:  Software  Monitoring 

LCCDSWS  shall  provide  the  user  with  graphic  feedback,  in  the  form  of 
warning  windows,  cues  and  alerts,  for  any  user  initiated  operations  which 
are  not  within  the  limits  of  established  functionality,  or  cannot  be  complied 
with  based  on  current  configuration  or  in  response  to  an  actual  system 
software  fault. 

G  2.3.3:  Recovery  Data 

The  system  shall  provide  the  user  with  the  capability  to  specify  some 
subset  of  system  data  for  system  recovery  in  the  event  of  equipment  failure, 
error  conditions  or  a  program  fault.  This  is  accomplished  by  specifying  the 
data  and  the  periodicity  for  which  that  data  shall  be  saved  to  some 
secondary  storage  device. 


G  2.4:  Training  Function 

The  system  has  to  support  the  determination  of  the  LCCDS  operational 
readiness  through  the  conduct  of  training  exercises.  We  refer  to  this 
function  as  the  Training  Function. 

Requirements  for  the  prototype  system  will  not  cover  the  refinement  for  the 
Training  Function.  However,  it  should  be  recognized  that  embedded  training 
functions,  developed  concurrently  with  the  actual  system,  will  have  a  large 
impact  on  fleet  acceptance  and  operator  training  at  the  unit  and  individual 
platform  level. 
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G  2.5:  Test  Function 


The  system  has  to  support  the  determination  of  the  LCCDS  material 
readiness  through  the  conduct  of  tests  and  associated  fault  processing.  We 
refer  to  this  function  as  the  Test  Function. 

Requirements  for  the  prototype  system  will  not  cover  the  refinement  for  the 
Test  Function. 

3.  The  Tactical  Database  Function 
a.  Preface 

The  Tactical  Database  is  one  of  the  important  integral  parts  of  the 
LCCDSWS.  NAVSEA  requires  [Appendix  A]  the  design/development  or  selection 
of  an  object-oriented  database  management  system  (OODBMS).  Ross  [Ref.  16] 
evaluates  three  commercially  available  OODBMS  as  candidates  for  the  LCCDS 
project  and  provides  a  survey  of  object-oriented  concepts.  To  identify  the  goals  for 
the  Tactical  Database  we  suggest  to  apply  an  object-oriented  development  method 
as  described  in  Booch  [Ref.  17],  The  design  of  a  system  is  performed  by  the 
following  steps  [Ref.  17:  p.  48]: 

1 .  Identify  the  objects  and  their  attributes. 

2.  Identify  the  operations  that  affect  each  object  and  the  operations  each 
object  must  initiate. 

3.  Establish  the  visibility  of  each  object  in  relation  to  other  objects. 

4.  Establish  the  interface  of  each  object. 

5.  Implement  each  object. 

However,  steps  3,  4  and  5  are  dependent  on  or  provided  by  the  OODBMS 
system  to  be  chosen.  These  steps  shall  be  the  subject  of  further  research  work  when 
an  OODBMS  system  is  selected  and  available. 
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Goals  3.2  and  3.3  try  to  identify  objects  for  the  Tactical  Database,  their 
attributes  and  operations.  It  is  assumed  that  these  sets  of  objects,  attributes  and 
operations  represent  minimum  sets  and  may  require  further  refinement. 

Goal  3.4  identifies  basic  input  and  output  operations  as  they  apply  to  all 
objects  in  the  data  base  or  on  particular  objects  with  respect  to  some  attributes  (e.g., 
objects  with  origin  "Local  Auto"  perform  I/O  operations  with  the  Radar  Interface). 
Again,  it  is  necessary  to  further  refine  these  operations  since  the  interfaces  are  not 
yet  defined. 


b.  Goals 

G  3:  Tactical  Database 

The  system  shall  provide  a  Tactical  Database.  We  refer  to  this  function  as 
the  Tactical  Database  Function. 

G  3.1:  Integrate  OODBMS  into  LCCDSWS 

The  Tactical  Database  shall  be  an  object  oriented  database  management 
system  (OODBMS).  It  shall  be  an  integral  part  of  the  LCCDSWS. 


G  3.2:  Provide  a  Set  of  Object  Types 

The  OODBMS  contains  information  necessary  to  establish  an  accurate 
picture  of  a  ship’s  environment.  The  unit  of  such  information  will  be  an 
object  within  the  OODBMS.  Information  necessary  to  generate  an  object 
can  be  provided  by  the  user,  an  external  system  (Radar,  Link  11)  or  an 
internal  module.  The  OODBMS  shall  provide  features  for  pre-defined 
objects  (statically  instantiated  objects)  and  for  objects  to  be  determined  at 
runtime  (dynamically  instantiated  objects).  Objects  are  described  by  their 
attributes  and  operations. 

G  3.2.1:  Types  of  Instantiated  Objects 

The  following  identifies  types  (classes)  of  statically  instantiated  objects,  a 
a  minimum  set  of  their  attributes  and  operations  in  terms  of  basic  CDS 
functions  as  described  in  Goal  3. 
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Class:  OWNSHIP 


Attributes:  Geographical  Position  {latitude  and  longitude} 

Time  of  Position  {hh:mm:ss} 

Course  {degrees} 

Speed  {knots} 

Origin  {Local  Manual} 

Tracknumber  {positive  integer  0  ..  9999} 

Type  {String  of  10  characters) 

Track  History  {<boolean>} 

Operations:  G  3.1.1:  Monitor  Ownship  Position, 

G  4. 1.1. 2:  Navigational  Computation, 

G  4. 1.2. 2:  CPA  Processing. 

Symbology:  An  object  of  class  OWNSHIP  is  associated  to  the  ownship 
symbol  as  described  in  Goal  1 . 1 . 1 . 1  (7). 

Class:  TENTATIVE  TRACK 

Attributes:  Geographical  Position  {latitude  and  longitude} 

Relative  Position  {bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  {hh:mm:ss} 

Course  {degrees} 

Speed  {knots} 

Category  {TENTATIVE} 

Identity  {UNKNOWN} 

Origin  (Local  Manual,  Local  Auto) 

Tracknumber  {positive  integer  0  ..  9999} 

Type  (String  of  10  characters} 

Operations:  G  4.2.1:  New  Track  Establishment, 

G  4.2.2:  Track  Position  Data, 
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G  4.2.3:  Track  Course  and  Speed  Determination, 

G  4.2.4:  Dead  Reckoning, 

G  4.3. 1.1:  Initial  Category  Assignment, 

G  4.3.2. 1:  Initial  Identity  Assignment, 

G  4.2.7. 1 :  Track  Termination. 

Symbology:  Objects  of  class  TENTATIVE  TRACK  are  associated  to  the 

tentative  track  symbol  as  described  in  G  1.1. 1.1:  (6) 

Class:  AIR  TRACK 

Attributes:  Geographical  Position  {latitude  and  longitude) 

Relative  Position  {bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  {hh:mm:ss} 

Course  {degrees) 

Speed  {knots} 

Height  (feet) 

Category  (AIR) 

Identity  {UNKNOWN  or  FRIENDLY  or  HOSTILE) 

Origin  {Local  Manual,  Local  Auto,  Remote) 

Tracknuinber  {positive  integer  0  ..  9999} 

Type  {String  of  10  characters) 

Class:  SURFACE  TRACK 

Attributes:  Geographical  Position  {latitude  and  longitude) 

Relative  Position  {bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  {hh:mm:ss} 

Course  {degrees) 

Speed  {knots} 

Category  (SURFACE) 
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Identity  (UNKNOWN  or  FRIENDLY  or  HOSTILE) 

Origin  (Local  Manual,  Local  Auto,  Remote) 

Tracknumber  (positive  integer  0  ..  9999) 

Type  (String  of  10  characters) 

Class:  SUBSURFACE  TRACK 

Attributes:  Geographical  Position  (latitude  and  longitude) 

Relative  Position  (bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  (hh:mm:ss) 

Course  (degrees) 

Speed  (knots) 

Depth  (feet) 

Category  (SUBSURFACE) 

Identity  ( UNKNOWN  or  FRIENDLY  or  HOSTILE) 

Origin  (Local  Manual,  Local  Auto,  Remote) 

Tracknumber  (positive  integer  0  ..  9999) 

Type  (String  of  10  characters) 

Operations  :  for  classes  AIR,  SURFACE  and  SUBSURFACE 
G  4. 1.2.2:  CPA  Processing, 

i* 

G  4.2.2:  Track  Position  Update, 

G  4.2.3:  Track  Course  and  Speed  Determination, 

G  4.2.4:  Dead  Reckoning. 

G  4.2.5:  Track  Position  Prediction, 

G  4.2.6:  Track  History  Processing, 

G  4. 2. 7. 2:  Manual  Termination 
G  4.3:  Identification  Function.. 

Note:  Due  to  several  similarities  in  the  attribute  sets  of  the  above  classes 
it  would  probably  be  appropriate  to  make  these  classes  subclasses  of  a 
class  TRACK. 
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During  further  refinement  and  implementation  it  should  be  considered  that 
the  set  of  operations  for  these  objects  depends  on  the  attribute  Origin 
(Local  Manual  ->  manual  tracking  functions;  Local  Auto  ->  auto  tracking 
functions,  Remote  ->  no  tracking). 

Symbology:  Objects  of  class  AIR  TRACK,  SURFACE  TRACK  and 
SUBSURFACE  TRACK  are  associated  with  the  track  symbols  as 
described  in  Goal  1.1. 1.1  (5),  Figure  21. 


Class:  REFERENCE  POINT 

Attributes:  Geographical  Position  {latitude  and  longitude} 

Relative  Position  (bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  {hh:mm:ss) 

Category  {SPECIAL} 

Identity  {REFPOINT} 

Origin  {Local  Manual) 

Operations  :  G  4. 1.3. 1 .3:  Enter  /update  Reference  Point, 

G  4. 1.2.2:  CPA  Processing, 

Symbology:  Objects  of  class  REFERENCE  POINT  are  associated  with 

the  Reference  Point  symbol  as  described  in  Goal  1 . 1 . 1. 1  (4). 

Glass:  NAVIGATION  HAZARD 

Attributes:  Geographical  Position  {latitude  and  longitude} 

Relative  Position  (bearing  in  degrees  and  distance  in  nm} 

Time  of  Position  {hh:mm:ss} 

Category  (SPECIAL) 

Identity  {NAVHAZ} 

Origin  {Local  Manual} 

Operations  :  G  4. 1.3. 1.3:  Enter /update  Navigation  Hazard, 

G  4. 1.2.2:  CPA  Processing, 
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Symbology:  Objects  of  class  NAVIGATION  HAZARD  are  associated 
with  the  Navigation  Hazard  symbol  as  described  in  Goa!  1.1. 1.1  (8). 

Class:  MAN  IN  WATER 

Attributes:  Geographical  Position  (latitude  and  longitude) 

Relative  Position  (bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  (hh:mm:ss) 

Category  (SPECIAL) 

Identity  (MAN  IN  WATER) 

Origin  (Local  Manual) 

Operations  :  G  4.1. 3. l.LEnter /update  Man  in  Water, 

G  4. 1.2.2:  CPA  Processing, 

Symbology:  Objects  of  class  MAN  IN  WATER  are  associated  with  the 
Man  in  Water  symbol  as  described  in  Goal  1.1. 1.1(9). 

Class:  WAYPOINT 

Attributes:  Geographical  Position  (latitude  and  longitude) 

Relative  Position  (bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  (hh:mm:ss) 

'  Steaming  Route  (integer  1..6) 

Category  (SPECIAL) 

Identity  (WAYPOINT) 

Origin  (Local  Manual) 

Operations:  G  4. 1.2.1:  Waypoint  Geometry. 

Symbology:  Objects  of  class  WAYPOINT  are  associated  with  the 
Waypoint  symbol  as  described  in  Goal  1.1.1.1(10). 
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Class:  DATA  LINK  REFERENCE  POINT 


Attributes:  Geographical  Position  {latitude  and  longitude) 

Time  of  Position  {hh:mm:ss} 

Category  (SPECIAL) 

Identity  (DLRP) 

Origin  {Local  Manual) 

Operations  :  G  4. 1.3. 1.1  -.Enter  /update  DLRP, 

G  4. 1.2.2:  CPA  Processing, 

Symbology:  Objects  of  class  DATA  LINK  REFERENCE  POINT  are 
associated  with  the  Data  Link  Reference  Point  symbol  as  described  in 
Goal  1.1.1.1(11). 

Class:  FORMATION  CENTER 

Attributes:  Geographical  Position  {latitude  and  longitude) 

Time  of  Position  {hh:mm:ss} 

Relative  Position  {bearing  in  degrees  and  distance  in  nm) 

Course  (degrees) 

Speed  (knots) 

Category  {SPECIAL) 

'  Identity  { FC } 

Origin  {Local  Manual) 

Operations  :  G  4. 1.3.1. 2:Enter /update  Formation  Center, 

G  4.2.4:  Dead  Reckoning, 

G  4. 1.2. 2:  CPA  Processing, 

Symbology:  Objects  of  class  FORMATION  CENTER  are  associated  with 
the  Formation  Center  symbol  as  described  in  Goal  1.1.1.1(12). 
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Class:  POSITION  AND  INTENDED  MOVEMENT 


Attributes:  Geographical  Position  (latitude  and  longitude} 

Relative  Position  (bearing  in  degrees  and  distance  in  nm) 

Time  of  Position  {hh:mm:ss} 

Course  (degrees} 

Speed  (knots) 

Category  (SPECIAL) 

Identity  (PIM) 

Origin  (Local  Manual} 

Operations  :  G  4.I.3.1.2:Eruer  /update  PIM, 

G  4.2.4:  Dead  Reckoning, 

G  4. 1.2. 2:  CPA  Processing, 

Symbology:  Objects  of  class  POSITION  AND  INTENDED  MOVEMENT 
are  associated  with  the  Position  and  Intended  Movement  symbol  as 
described  in  Goal  1.1.1.1(12). 

Note:  Due  to  several  similarities  in  the  attribute  sets  of  the  above  classes 
it  would  be  appropriate  to  make  these  classes  subclasses  of  a  class 
SPECIAL  POINT. 


G  3.3:  Definition  of  New  Classes 

i* 

The  OODBMS  shall  allow  the  user  to  define  new  classes  of  objects  at 
runtime  by  choosing  from  a  set  of  attributes  and  operations.  The  definition 
of  a  new  class  shall  allow  the  user  to  instantiate  objects  of  that  class. 

For  the  definition  of  a  new  class  the  user  shall  be  allowed  to  construct  the 
definition  by  selection  from  a  given  set  of  attributes  and  operations  or  by 
defining  new  attributes  or  operations. 
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It  is  recommended  that  attributes  be  further  divided  in  specific  and  generic 
attributes.  Specific  attributes  may  include: 

-  position  { lat/long } 

-  course  {degrees} 

-  speed  {knots} 

-  relative  position  {bearing/distance} 

-  category  {AIR,  SURFACE,  SUBSURFACE}. 

Generic  attributes  may  include: 

-charactcr/texiuelda 
-numeric  fields 
-floating  value  fields 
-date  fields 
-time  fields 
-logical  fields. 

In  the  following  we  provide  an  example  for  a  user  defined  class: 

Class:  USERDEFINED 

'  Attributes:  minimal  set  is: 

Geographical  Position  {latitude  and  longitude) 

Time  of  Position  {hh:mm:ss) 

C  character/textfields 
N  numeric 
F  floating  value 
D  date 
T  time 
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L  Logical 
DD  <condition> 

Symbology:  Objects  of  class  USERDEFINED  are  associated  with  the 
Userdefined  symbol  as  described  in  Goal  1.2. 1.4. 


G  3.4:  Provide  Input  and  Output  for  OODBMS 

The  OODBMS  shall  provide  features  for  data  entries  and  output. 

G  3.4.1:  Interaction  with  MMI 

The  OODBMS  shall  interact  with  the  MMI. 

G  3.4.1. 1:  MMI  Input 

The  OODBMS  shall  accept  all  user  input  operations  through  the  MMI. 
Input  shall  be  graphical  input,  alphanumerical  input  or  functional  input. 

G  3.4.1. 1.1:  Graphical  Input 

A  graphical  input  is  an  input  from  the  graphic  I/O  portion  of  the  MMI  as  a 
result  of  a  user  input  on  the  TacPlot  converted  to  a  geographical  position. 

The  OODBMS  shall  accept  the  geographical  position  and  perform  one  of  the 
following  depending  on  user  specified  functions/conditions: 

"hooking"  of  an  object  that  can  be  associated  with  a  symbol  located  at 
that  position. 

*  -  instantiation  of  an  object  of  class:  TENTATIVE  TRACK,  "hooking"  of 
that  object  and  provide  for  operations  as  described  in  Goal  3.2.1. 

instantiation  of  an  object  of  class:  SPECIAL  POINT,  "hooking"  of  that 
object  and  provide  for  operations  as  described  in  Goal  3.2.1. 

G  3.4.1. 1.2:  Alphanumerical  Input 

An  alphanumerical  input  is  an  input  from  the  alphanumeric  I/O  portion  of  the 
MMI  as  the  result  of  a  user  input  to  an  alphanumeric  I/O  window  The 
OODBMS  shall  accent  the  alphanumerical  input  and  update  the  objects  that 
can  be  associated  with  that  input  (e.g.,  objects  being  hoiked,  conditions 
specified  by  user  for  a  set  of  objects). 
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G  3.4.1. 1.3:  Functional  Input 

A  functional  input  is  an  input  from  the  Function  I/O  portion  of  the  MMI  as 
the  result  of  a  user  manipulation  to  a  functional  window  (button,  icon,  etc.). 
The  OODBMS  shall  accept  the  functional  input  and  perform  the  operations 
on  applicable  objects  as  described  in  Goal  4. 

G  3.4.1.2:  MMI  Output 

The  OODBMS  shall  output  all  data  to  the  user  through  the  MMI. 

G  3.4.1. 2.1:  Graphical  and  Alphanumerical  Output 

The  OODBMS  shall  automatically  generate  a  stream  of  objects  for  use  by 
the  MMI  Graphic  I/O  and  Alphanumeric  I/O: 

(1)  for  graphical  output;  all  objects  that  qualify  for  output. 

(2)  for  alphanumeric  output: 

-  the  object  of  class  OWNSHIP  at  all  time. 

-  one  hooked  object  that  qualifies  for  output. 

-  by  user  functions  specified  objects. 

The  change  of  an  alphanumeric  output  shall  result  in  an  alphanumeric  input 
operation. 


G  3.4.2:  Interaction  with  Tracking  System 

The  OODBMS  shall  interact  with  a  Tracking  System. 


G  3.4.3:  Interaction  with  Radar  Interface 

The  OODBMS  shall  interact  with  the  Radar  Interface. 


G  3.4.4:  Interaction  with  Link  11  Interface 

The  OODBMS  shall  interact  with  the  Link  1 1  Interface. 
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G  3.4.5:  OODBMS  System  Alerts 


The  OODBMS  shall  provide  system  alerts  for  output  on  the  alphanumeric 
I/O  portion  of  the  MMI  when: 

-  an  invalid  operation  on  an  object  is  issued; 

-  an  invalid  condition  for  an  object  is  specified; 

-  a  relationship  between  objects  cannot  be  established. 

G  3.5:  Query  Language 

The  goal  for  the  query  language  can  not  be  further  refined  at  this  time. 
Specifics  of  the  query  language  will  depend  on  the  OODBMS  to  be  selected 
or  to  be  designed. 


4.  The  Basic  CDS  Functions 

a.  Preface 

The  functions  as  described  in  the  following  are  mainly  extracted  from 
Reference  7.  They  represent  the  subset  of  CDS  functions  applicable  to  LCCDS.  In 
the  context  of  LCCDSWS  these  functions  can  be  classified  as  follows: 

(1)  CDS  functions  that  are  operations  on  objects  as  specified  in  G2;  these 
operations  fall  in  two  categories: 

-  Manually  functions  that  are  initiated  on  user  request  at  the  MMI; 
e.g.  a  manual  position  update 

-  Automatic  functions  that  are  performed  by  the  system  without  user 
interference. 

(2)  CDS  functions  that  represent  new  classes  not  covered  by  Goal  3. 

(3)  CDS  functions  that  represent  modules  within  the  LCCDSWS. 

b.  Goals 

G  4:  The  Basic  CDS  Functions 

The  system  has  to  support  the  user  to  establish  an  accurate  picture  of  a 
ships  environment.  We  refer  to  this  function  as  the  Basic  CDS  Function. 
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G  4.1:  Ownship  Monitor  Function. 

G  4.1.1:  Monitor  Ownship  Position 

The  system  has  to  maintain  the  ownship  symbol  in  the  center  of  the  TacPlot 
as  a  default. 

The  system  shall  maintain  current  and  actual  information  concerning 
position  and  velocity  of  ownship.  It  shall  accept  both  manual  and  automatic 
navigational  inputs. 

G  4.1. 1.1:  Manual  Inputs 

The  system  shall  provide  the  operator  with  the  capability  to  enter  the 
following  navigation  inputs: 

-  Enable/Disable  I/O  channel  to  Navigational  System; 

-  Julian  Date; 

-  Marktime  (Nav  Sys  must  be  enabled); 

-  Greenwich  Mean  Time  (GMT)  (Nav  Sys  must  be  enabled); 

-  Ownship  heading  (Nav  Sys  must  be  enabled); 

-  Ownship  speed  (Nav  Sys  must  be  enabled); 

-  Ownship  latitude  and  longitude  (Nav  Sys  must  be  enabled); 

-  True  or  relative  bearing  and  range  to  a  Special  Point. 

G  4.1. 1.2:  Automatic  Inputs 

*  The  system  shall  accept  the  following  navigational  inputs  from  a 
Navigational  System: 

-  Ownship  latitude  and  longitude 

-  Ownship  heading 

-  Ownship  speed 

-  GMT 

G  4.1. 1.3:  Navigational  Computation 

The  system  shall  update  ownship  position  and  velocity  at  a  minimum  of 
once  every  four  seconds  based  on  the  positional  data  received  from  either 
manual  or  automatic  input. 
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The  system  shall  provide  the  following  capabilities  for  manually 
repositioning  ownship: 

The  system  shall  provide  the  capability  to  reposition  ownship  relative  to  a 
geographically  fixed  Special  Point  resulting  in  adjustments  to  ownship 
latitude  and  longitude; 

The  system  shall  provide  automatic  dead  reckoning  calculations  for  ownship 
latitude  and  longitude  position  based  on  the  last  position,  course  and  speed. 


G  4,1.2:  Monitor  Ownship  Surface  Maneuvering 

The  system  shall  provide  the  following  ownship  maneuvering  capabilities: 

G  4. 1.2.1:  Waypoint  Geometry 

The  system  has  to  allow  for  specification  of  up  to  six  steaming  routes  with 
up  to  50  waypoints  (destinations)  per  route. 

The  system  shall  determine  the  course  at  a  specified  speed,  that  a  vehicular 
track  or  the  ownship  must  take  in  order  to  intercept  a  designated  waypoint. 

The  system  shall  update  the  maneuvering  geometries  every  4  seconds. 

Waypoint  maneuvering  data  shall  be  presented  with  course,  speed,  bearing 
and  distance  to  the  waypoint  and  shall  include  the  GMT  of  the  estimated 
arrival  time  at  the  waypoint,  the  waypoint  designation  and  Time-To-Go  to 
the  waypoint. 

G  4.1.2.2:  Closest  Point  of  Approach  Processing 
* 

The  system  has  to  provide  Closest  Point  of  Approach  (CPA)  geometry  from 
ownship  to  any  track  and  between  any  two  tracks  upon  user  request. 

When  the  CPA  of  a  specified  track  meets  specified  time  and  range  criteria, 
the  user  shall  be  notified  of  a  Close  CPA  or  Collision  CPA  as  appropriate. 
The  system  shall  allow  the  user  to  manually  adjust  the  criteria  for  Close 
CPA  and  Collision  CPA  calculations  and  alert  as  follows: 

-  Close  CPA  Range:  200  -  9,999  yards; 

-  Close  CPA  Time:  5  -  99  minutes; 

-  Collision  CPA  Range:  1-199  yards 

-  Collision  CPA  Time:  5  -  99  minutes; 
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Preset  parameters  for  CPA  calculations  shall  be  requested  from  the  user 
upon  system  initialization. 

G  4.1.3:  Monitor  Surface  Area  Management 
G  4.1.3.1:  Special  Points 

The  system  shall  provide  for  the  following  types  of  Special  Points: 

-  Man  in  Water; 

-  Formation  Center; 

-  Position  and  Intended  Movement  (PIM) 

-  Navigation  Hazard; 

-  Data  Link  Reference  Point  (DLRP); 

-  Reference  Point. 

G  4.1.3.1.1:  Man  in  Water 

The  system  shall  provide  the  capability  to  enter  and  reposition  up  to  ten 
Man-in-Water  special  points.  The  coordinates  of  entry  shall  be  user 
specified  by  ball  tab  coordinates  The  position  of  the  Man-ln-Water  shall  be 
geographically  fixed.  The  Man-in-Water  Special  Point  shall  be  terminated 
manually  on  user  request. 

G  4. 1.3. 1.2:  Formation  Center  and  PIM 

The  system  shall  provide  the  user  with  the  capability  to  enter/update  the 
following  special  points: 

-  Formation  Center  (FC) 

-  Position  and  Intended  Movement  (PIM) 

Entries  shall  include  latitude,  longitude,  course  and  speed  of  the  designated 
special  points. 

The  user  shall  have  the  capability  to  enter,  slave  or  reposition  the  special 
point  using  ball  tab  coordinates.  Repositioning  shall  not  cause  automatic 
course  and  speed  recalculation. 

Both  Special  Points  shall  be  terminated  upon  user  request. 
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G  4. 1.3. 1.3:  Navigation  Hazards  and  Reference  Points 

The  system  shall  provide  the  user  with  the  capability  to  enter/update  the 
special  points: 

-  Navigation  Hazard; 

-  Reference  Point. 

The  entries  shall  include  latitude  and  longitude  of  the  designated  special 
point.  Both  Special  Points  shall  be  terminated  upon  user  request. 


G  4. 1.3. 1.4:  DLRP 


The  system  shall  provide  the  user  with  the  capability  to  enter/update  a 
DLRP.  Entries  shall  include  latitude  and  longitude  of  the  DLRP.  Once 
entered  a  DLRP  cannot  be  terminated. 

G  4. 1.3.2:  Chart  Processing 

The  system  shall  provide  the  ability  to  overlay  the  TacPlot  with  World 
Vector  Shoreline  maps  as  available  from  the  Defense  Mapping  Agency  or 
other  sources. 


G  4.2:  Tracking  Function. 

The  Tracking  Function  is  the  manual  entry  and  manual  or  automatic  update 
of  position,  course  and  speed  of  applicable  vehicular  tracks  as  required  by 
Increment  Two.  It  represents  operations  applicable  to  objects  as  described 
in  Goal  2. 

G  4.2.1:  New  Track  Establishment 

The  system  shall  provide  the  capability  to  enter  new  tracks  manually. 

A  newly  entered  vehicular  track  shall  be  initiated  as  a  tentative  track. 

The  system  shall  determine  when  local  track  entries  are  sufficiently  reliable 
to  warrant  a  firm  track  status.  Firm  track  status  shall  be  based  on  the 
number  of  updates.  Firm/tentative  status  shall  only  apply  to  vehicular 
tracks. 

The  tentative  tracks  shall  become  firm  tracks  as  a  result  of  one  of  the 
following  conditions: 
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-  After  three  manual  position  updates  as  described  in  Goal  4.2.2. 1. 

-  Manual  category  entered  before  three  position  updates  in  accordance 
with  Goal  4.3. 1.2. 

-  Manual  declared  firm. 


G  4.2.2:  Track  Position  Data 
(i  4. 2.2.1:  Track  Position  Update 

The  user  shall  have  the  capability  to  perform  manual  position  (range  and 
bearing)  update  entries  for  all  vehicular  tracks. 

The  result  of  these  position  corrections  shall  be  the  update  of  the  tracks 
position  in  all  cases.  It  shall  also  result  in  automatic  course  and  speed 
computation. 

G  4.2.2. 2:  Track  Reposition 

The  user  shall  have  the  capability  to  reposition  vehicular  tracks. 

The  result  of  the  reposition  action  shall  be  update  of  the  track’s  position  in 
all  cases.  It  shall  not  cause  au.omatic  course  and  speed  recomputation. 

G  4.2.3:  Track  Course  and  Speed  Determination 

The  system  shall  provide  for  the  determination  and  entry  of  a  track  course 
and  speed. 

G  4.2.3.1:  Course  and  Speed  Computations 
* 

The  system  shall  automatically  compute  the  course  and  speed  for  the 
following: 

-  A  newly  entered  track. 

-  Any  track  on  which  a  position  update  is  taken. 

G  4. 2.3. 2:  Manual  Course  and  Speed  Entries 

The  system  shall  provide  the  capability  to  enter  course  and  speed  manually 
for  the  following  tracks: 

(1)  Vehicular  Tracks.  Course  and  speed  shall  be  accepted  for  all  vehicular 
tracks  with  bearing  values  in  degrees  and  speed  values  in  up  to  9999 
knots. 
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(2)  Special  Points.  Course  and  speed  shail  be  accepted  for  the  following 
unslaved  unique  special  Points: 

-  Formation  Center. 

-  P1M 


G  4.2.4:  Dead  Reckoning 

The  system  shall  automatically  perform  Dead  Reckoning  computations  for 
all  vehicular  tracks  via  an  extrapolation  of  the  last  known  position,  course 
and  speed.  If  no  Track  Position  Update  (Goal  4.2.2. 1)  is  received  for  a 
vehicular  track  w.ihin  4  seconds,  the  track  shall  be  automatically 
repositioned.  This  shall  not  cause  automatic  course  and  speed  computation. 


G  4.2.5:  Track  Position  Prediction: 

The  system  shall  compute  predicted  track  positions  on  user  selected 
vehicular  tracks  via  an  extrapolation  of  the  last  known  position,  course  and 
speed. 

The  prediction  rate  shall  be  4  seconds. 


G  4.2.6:  Track  History  Processing 

The  system  shall  maintain  history  positional  data  on  all  air,  surface  and 
subsurface  vehicular  tracks.  The  points  shall  be  displayed  upon  request  for 
'  ar  individual  track. 

Normal  manual  track  history  shall  be  provided  for  the  following: 

-  Ownship 

-  Air  Vehicular  Track 

-  Surface  Vehicular  Track 

-  Subsurface  Vehicular  Track 


G  4.2.7:  Track  Termination 

The  system  shall  provide  for  the  manual  and  automatic  termination  of  all 
local  tracks  by  responding  to  Drop  Track  notifications  by  deleting  the 
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specified  track  from  the  track  stores,  erasing  its  symbol  on  the  screen  and 
notifying  the  user, 

G  4.2.7.1:  Automatic  Termination 

The  system  shall  provide  for  automatic  termination  of  vehicular  tracks  as 
follows: 

Tentative  Track:  if  no  update  is  received  within  6  minutes  for  an  air 
track  or  12  minutes  for  an  surface  track. 

Track  termination  shall  be  performed  on  user  confirmation  only. 

G  4.2.7.2:  Manual  Termination 

The  system  shall  provide  the  capability  to  manually  terminate  a  specified 
track. 

Tracks  that  have  other  tracks  slaved  to  them  shall  not  be  dropped  until  all 
slaved  tracks  have  been  dropped. 

Special  points  that  shall  not  be  dropped  once  they  have  entered  are: 

-  Ownship 

-  Data  Link  Reference  Point  (DLRP) 


G  4.3:  Identification  Function 

The  system  shall  perform  the  determination  of  Category  and  Identity  of 
applicable  tracks. 

G  4.3.1:  Track  Category  Determination 

The  system  shall  perform  vehicular  track  category  determination.  The 
categories  to  be  assigned  are  AIR,  SURFACE  and  SUBSURFACE. 

G  4.3.1. 1:  Initial  Category  Assignment 

The  system  shall  assign  a  category  to  all  new  vehicular  tracks  on  initial 
entry.  The  initial  category  assignment  shall  be  based  on  category  speed  as 
follows: 

-  speed  less  than  category  speed:  SURFACE; 

-  speed  greater  category  speed:  AIR. 
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The  category  speed  shall  be  user  modifiable,  the  preset  value  shall  be  50 
knots. 

G  4.3. 1.2:  Category  Change  Processing 

The  user  shall  be  provided  with  the  capability  of  manually  changing: 

-  the  category  of  all  firm  vehicular  tracks; 

-  category  of  a  tentative  track  for  New  Track  Establishment  (Goal  4.2. 1 ). 

G  4.3.2:  Track  Identity  Determination 

The  system  shall  perform  a  vehicular  track  identity  determination.  Track 
identities  are  UNKNOWN,  FRIEND  and  HOSTILE. 

G  4.3.2. 1:  Initial  Vehicular  Track  Identity  Assignment 

The  system  shall  assign  a  vehicular  track  the  identity  UNKNOWN  upon 
new  track  establishment  (Goal  4.2.1). 

G  4.3.2.2:  Vehicular  Track  Identity  Change  Processing 

The  user  shall  be  capable  of  changing  the  identity  of  all  vehicular  tracks  . 


G  4.4:  Search  and  Detection  Function 

The  Search  and  Detection  Function  is  the  search  for,  detection  and  entry  of 
vehicular  tracks  by  ownship  sensors.  Ownship  sensors  for  LCCDS  are 
assumed  to  be  search  radars  only.  This  goal  represents  the  radar  interface 
(TBD)  and  auto  tracking  capability  of  Increment  four. 

G  4.4.1.:  Radar  Interface 

The  system  has  to  provide  external  interfaces  to  search/navigational  radar 
systems.  Since  the  characteristics  of  the  radar  are  not  yet  known,  a  detailed 
refinement  cannot  be  provided  at  this  time  and  shall  be  part  of  further 
research. 

G  4.4.2.:  Interface  Radar  and  OODBMS 

The  system  has  to  provide  an  internal  interface  between  the  OODBMS  and 
the  radar.  The  information  passed  from  radar  to  OODBMS  shall  result  in 
the  instantiation  of  objects  of  class  TENTATIVE  TRACK  and  initiate  new 
track  establishment  as  described  in  Goal  4.2.1  or  shall  be  used  to  update 
the  positions  of  existing  objects  as  described  in  Goal  4.2.2. 1. 
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G  4.5:  Communication  Function. 


The  system  shall  support  the  establishment  and  maintenance  of  digital 
communications. 

G  4.5.1:  Link  11 

Implement  an  external  communication  function  as  described  in  Increment 
five  based  on  a  TBD  classified  Interface  Design  Specification. 


G  4.6:  Tableau  System 

The  LCCDSWS  shall  provide  detailed  information  on  all  aspects  of  the 
tactical  situation  and  system  control,  operating  parameters  and  status. 
This  information  shall  be  indexed  for  easy  user  access  and  presented  in 
tableau  form  using  Alphanumeric  I/O  windows. 

These  "tableaux"  of  information  shall  be  directly  accessible  by  the  user,  or 
be  automatically  displayed  as  a  result  of  some  program  action.  In  any  case, 
these  tableaux  should  be  context  sensitive,  providing  a  lower  level  of  detail 
on  demand  or  as  a  support  function  of  some  related  process. 

G  4.6.1:  Basic  Features 

The  purpose  of  the  Tableau  system  is  to  provide  the  user  with  the  detailed 
information  he  sometimes  needs  without  cluttering  or  confusing  the  tactical 
picture  presented  on  the  TacPlot. 

One  important  feature  of  the  Tableau  system  is  to  provide  a  formatted,  well 
"  organized  summary  of  functions  defined  by  the  user  via  some  complex,  and 
possibly  lengthy,  series  of  menu  choices  and  Alphanumeric  inputs.  A  prime 
example  of  this  situation  is  the  Display  Doctrine.  It  may  be  a  complicated 
process  to  create  Display  Doctrine  statements  involving  very  rigidly 
structured  sequences  of  menu  options  and  dialog.  The  user  must  be  able  to 
review  what  he’s  built,  and  certainly  refer  to  it  later,  in  some  direct  and 
efficient  manner. 

G  4.6.2:  Tableau  Representation 

Tableaux  shall  be  represented  using  Alphanumeric  I/O  windows.  These 
windows  shall  have  the  resize,  reposition  and  scroll  capability  as  outlined 
in  the  MMI  conventions  (Goal  1.1. 1.2).  However,  these  functions,  as  well 
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as  the  capability  for  user  input  data  directly  into  a  tableau,  should  be 
considered  on  a  case-by-case  basis  depending  on  the  structure  and  content 
of  each. 

G  4.6.3:  Tableau  Types 

There  is  a  large  body  of  tactical  reference  material  which  does  not  require 
continuous  display,  but  should  be  quickly  available  to  the  user.  Much  of  the 
information  currently  maintained  on  plexiglass  "grease  boards”  fits  into  this 
category  and  should  be  maintained  on  the  LCCDS  in  tableau  form. 

In  addition  to  the  default  tableaus  provided  with  the  system,  the  user  shall 
have  the  capability  of  defining  new  ones  for  specific  purposes  and  adding 
them  to  the  Index  tableau.  User  defined  tableaus  shall  be  created  using 
menu  choices  and  fill-in-the-blank  templates  in  much  the  same  style  as  the 
Display  Doctrine  constructors  (Goal  1.3). 

The  following  default  types  of  information  tableaus  are  provided  to  further 
describe  the  functionality  and  concept  of  use.  They  shall  be  considered  a 
minimum  set. 

G  4.6.3. 1:  Index 

The  Index  tableau  shall  provide  a  list  of  all  default  and  user-defined 
tableaux.  This  index  shall  be  represented  in  a  standard  support  window 
format  (Goal  1.1. 1.2. 1.2.4)  using  one  of  the  scroll  features  to  scan  the  list 
using  the  Trackball  pointer.  The  user  should  be  able  to  move  to  the  desired 
area  of  the  list  using  the  scroll  bar  and  then  highlight  (by  pointing  with  the 
trackball)  to  the  tableau  to  be  displayed.  A  conceptual  example  of  this 
'  window  is  provided  in  Figure  27. 
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G  4.6.3.2:  Navigation 

The  Navigation  tableau  shall  provide  detailed  information  on  ownship 
navigation  including,  but  not  limited  to,  the  following: 

r  -  time  (standard  GMT  and  local  format  -  hh:mm:ss) 

-  lai/long  position  (dd:mm:ss) 

-  course  (relative  to  true  and  magnetic  north  -  000.0  T/M) 

-  speed  (000.0  knots) 

-  magnetic  variation  (degrees  East/West  -  00.0  E/W) 

-  set  (degrees  true  -  000.0  T) 

-  drift  (speed  in  knots  -  000.0) 

-  wind  direction  (degrees  true  -  000.0  T) 

-  wind  speed  (speed  in  knots  -  000.0) 
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-  distance  to  next  waypoint  (NM  great  circle  or  rhumb  (direct)  distance) 

-  ETA  next  waypoint  (DTG  format  -  212030Z  JUN  90) 

-  ETE  next  waypoint  (hh:mm:ss) 

-  Navigation  source  (inertial,  SATNAV,  Omega,  DR,  etc.) 

G4.6.3.3:  PIM 

The  PIM  tableau  shall  maintain  continuous  status  of  Ownship  progress 
along  a  selected  steaming  route  defined  in  the  Float  Plan  tableau.  This 
tableau  shall  provide  the  following  information: 

-  PIM  course  and  speed 

-  current  PIM  position 

-  Ownship  distance  ahead/behind  PIM 

-  ETE  to  PIM  (based  on  current  or  user  entered  trial  course/speed) 

G  4.6.3.4:  Float  Plan 

This  tableau  provides  the  user  a  tool  for  defining  up  to  six  steaming  routes 
of  up  to  50  waypoints  each.  Each  waypoint  is  defined  by  a  latitude 
(dd:mm:ss  N/S)  and  longitude  (dd:mm:ss  E/W).  A  steaming  route  shall 
consist  of  a  numbered  list  (in  order  of  entry)  of  waypoints.  The  user  shall, 
at  any  time,  be  allowed  to  edit  this  tableau  by  selecting  the  desired 
steaming  route  and  modifying,  adding  or  deleting  one  or  more  of  its 
associated  waypoints. 

It  is  highly  recommended  that  the  content  and  format  of  the  Float  Plan 
*  steaming  routes  follow  the  structure  of  the  PIM  portion  of  OPGEN 
ALPHA.  This  form  is  supported  by,  and  described  in  detail  in,  the  NCCS-A 
MMI  specification  [Ref.  29:pp.  75-79]. 

G  4.6.3.S:  Communications 

The  Communications  tableau,  or  set  of  related  tableaux,  shall  provide  all 
essential  information  regarding  radio  and  link  circuits,  frequencies,  crypto 
change-over  times,  daily  call-signs  for  desired  friendly  units.  Additionally, 
it  should  provide  a  menu  of  selectable  message  templates  for  various 
reports. 
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G4.6.3.6:  Active  Tracks 


The  Active  Tracks  tableau  shall  provide  a  list  of  all  tracks  currently  held  in 
the  Tactical  Database  along  with  time  of  last  update.  This  list  shall  be 
represented  in  a  standard  support  window  format  (Goal  1.1. 1.2. 1.2.4)  using 
one  of  the  scroll  features  to  scan  the  list  using  the  Trackball  pointer.  The 
user  should  be  able  to  move  to  the  desired  area  of  the  list  using  the  scroll 
bar  and  then  highlight  (by  pointing  with  the  trackball)  any  track.  Clicking  on 
the  highlighted  track  will  display  all  the  detailed  information  (from  the 
Tactical  Database)  pertaining  to  it.  This  information  shall  be  presented  in 
the  Selected  Track  tableau  (Goal  4.6.2). 

G  4.6.3.7:  Selected  Track 

\  his  tableau  provides  all  the  information  held  in  the  Tactical  Database 
pertaining  to  the  selected  track  (chosen  from  the  Active  Tracks  tableau). 

G  4.6.3.8:  Display  Doctrine 

The  Display  Doctrine  tableau  shall  enable  the  user  to  view  all  existing 
Display  Doctrine  statements.  This  tableau  should  be  an  Info  object, 
allowing  the  user  to  view  the  data,  but  not  change  it.  Changes  should  be 
made  only  through  the  Display  Doctrine  menu  dialog  sequence  described  in 
Goal  1.3. 

G  4.6.3.9:  Data  Link  Control 

This  tableau  shall  display  Link  1 1  control  parameters  and  amplifying 
information.  The  Link  11  control  parameters  shall  include  ownship  track 
*  number  (TN),  DLRP  lat/long,  and  TN  pool.  Amplifying  information  on  other 
Link  11  participating  units  (PU’s)  including  TN  and  platform  type,  shall  also 
be  provided. 

G  4.6.3.10:  System  Status 

The  System  Status  tableau  maintains  the  current  operational  status  of  all 
LCCDS  software,  hardware  and  external  interfaces.  This  tableau  shall  be 
updated  automatically  based  on  program  and  user  action  regarding  system 
initialization  parameters,  selected  interfaces,  LCCDS  hardware 
configuration  and  availability  and  current  state  of  the  operational  software. 

An  important  feature  of  this  tableau  shall  be  the  capability  for  the  user  to 
manually  inhibit  the  function  of  any  hardware,  interface  or  software 
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component  based  on  mission  requirements,  operational  status,  etc.  For 
instance,  in  an  emission  control  environment  (EMCON)  the  user  shall  have 
a  method  for  disabling  the  Radar  interface  to  preclude  unauthorized  or 
accidental  radiation. 

G  4.6.3.11:  User  Defined  Tableaux 

The  system  shall  provide  the  user  with  the  capability  to  define  both  static 
and  dynamic  tableaus.  The  specific  content  and  usage  shall  be  determined 
locally  by  the  user  (or  user’s  command)  and  constructed  in  much  the  same 
manner  as  the  Display  Doctrine  using  "smart"  templates  and  forms  with 
appropriate  ranges  of  available  choices. 

The  differentiation  between  static  and  dynamic  tableaux  is  the  degree  of 
complexity  involved.  Static  tableaux  contain  information  provided  by  the 
user  and  is  not  maintained,  changed  or  updated  by  program  action. 
Procedures,  checklists,  etc.  are  examples  of  the  type  of  information 
available  through  static  tableaux. 

Dynamic  tableaux  are  more  complicated  to  define  because  it  is  intended 
that  the  program  will  somehow  act  upon  or  effect  their  contents.  The 
purpose  and  functionality  of  dynamic  tableaus  shall  be  very  carefully 
restricted,  providing  clear  guidelines  for  the  available  range  of  user  defined 
operation.  The  main  source  of  on-line  information  to  be  made  available  for 
use  in  these  tableaux  shall  be  the  Tactical  Database. 


G  5:  Implementation  in  Steps 

P 

The  system  is  supposed  to  be  modularized  to  allow  an  implementation  in 
incremental  steps. 


G  6:  LCCDSWS  is  highly  Concurrent 

The  system  is  supposed  to  be  highly  concurrent  and  prepared  for  future 
extensions.  Possible  extensions  are  described  in  Chapter  V  as  evolution  of 
the  system. 
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G  6.1:  Provide  Real-Time  Scheduling  and  Allocation 

The  system  shall  provide  internal  scheduling  and  allocation  of  the  processor 
and  resources  to  real  time  requirements. 

G  6.2:  Process  Load  Orders  in  Real-Time 

The  system  shall  process  program  load  orders  in  real  time. 
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III.  LCCDS  ESSENTIAL  MODEL 


This  chapter  provides  a  high  level  structural  analysis  of  the  LCCDS  using  the 
Essential  (Yourdon)  model  |Ref.  18].  Yourdon’s  Essential  model  attempts  to  define 
what  the  system  must  do  in  order  to  satisfy  the  user’s  requirements  while  avoiding 
any  implementation  level  details.  It  is  a  logical,  conceptual  model  of  the  system. 

The  Essential  model  is  comprised  of  two  basic  components;  the  Environmental 
model  and  the  Behavioral  model.  Yourdon’s  Environmental  model  has  some  overlap 
with  the  goal  tree  component  of  Berzins’  model  (used  for  the  informal  requirements 
analysis  provided  in  Chapter  Two).  Both  attempt  to  define  the  boundary  between 
system  and  external  world.  The  major  distinction  between  the  two  is  that  Yourdon’s 
Environmental  model  includes  more  detail  on  external  communications  requirements 
in  the  form  of  an  Event  List. 

The  Behavioral  model  tries  to  define  the  internal  processes  and  data  objects 
necessary  for  supporting  the  "events"  interacting  with  the  external  world.  Events  are 
defined  as  external  stimuli  to  which  the  system  must  somehow  respond  [Ref.  18:p. 
340],  The  Behavioral  model  is  a  lower-level  definition  of  the  system,  utilizing  data 
flow  diagrams,  entity-relationship  diagrams,  state-transition  diagrams,  data 
definition  (dictionaries)  and  process  specifications. 

The  Essential  model  therefore  provides  an  important  link  between  informally 
stated  user  desires  and  eventual  functional  capabilities  of  the  system.  It  provides  a 
tool  for  the  system  analyst  to  model  the  desired  system  at  a  level  high  enough  to  be 
understandable  to  the  user  and  still  provide  the  necessary  guidance  for 
implementation. 


105 


A.  The  Environmental  Model 


1.  The  Statement  of  Purpose 

The  purpose  of  the  project  reported  here  is  to  develop  the  prototype  of  a 
software  system  for  a  Low  Cost  Combat  Direction  System  (LCCDSWS)  that 
implements  the  basic  features  of  a  Combat  Direction  System  on  a  commercially 
available  microprocessor  based  workstation. 

The  purpose  of  the  LCCDS  software  system  is  to  maintain  and  display  a  real¬ 
time  tactical  picture  of  a  naval  vessel’s  external  environment.  This  includes 
generating,  tracking  and  managing  all  air,  surface  and  subsurface  tracks  for  a  given 
geographic  area,  Special  Points  and  shoreline  maps. 

2.  The  Context  Diagram 

The  context  diagram  pictured  below  in  Figure  28  is  identical  to  the  initial 


Figure  28:  The  Context  Diagram  (from  Figure  10,  page  21) 


context  diagram  in  Figure  10  and  is  provided  here  for  convenience.  The  meaning  and 
use  of  the  context  diagram  is  the  same  for  both  the  Berzins  and  Yourdon  models. 
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3.  The  Event  List 


The  event  list  is  an  informal  description  of  the  events  which  take  place  in  the 
external  environment  to  which  the  LCCDS  must  respond.  Events  are  defined  from 
the  perspective  of  the  external  world,  i.e.,  from  the  outside  looking  in  [Ref.  18:p.  351  [  . 

1.  Operator  receives  request  for  system  initialization. 

2.  Operator  sends  system  initialization  parameters  (Goal  2.1). 

3.  System  displays  TacPlot  (Goal  1.2.1). 

4.  TacPlot  displays  ownship  symboKGoal  1.2. 1.1  (7)). 

5.  TacPlot  is  refreshed  corresponding  to  ownship  position  (Goal  4.1.1). 

6.  Operator  enables  interface  to  navigation  system  (Goal  2.2.1). 

7.  Navigation  system  sends  ownship  messages  every  3  minutes. 

8.  Operator  disables  interface  to  navigation  system  (Goal  2.2.1). 

9.  Operator  enables  interface  to  radar  system  (Goal  2.2. 1 ). 

10.  Radar  system  sends  radar  messages. 

1 1.  TacPlot  displays  radar  track  symbols. 

i» 

12.  Radar  track  symbols  are  repositioned  or  updated  on  Tacplot  (Goal  4.2.4). 

13.  Operator  disables  interface  to  radar  system  (Goal  2.2.1). 

14.  Operator  enables  interface  to  Link  1 1  system  (Goal  2.2.1). 

15.  Link  1 1  system  sends  Link  messages. 

16.  Link  1 1  track  symbols  are  displayed  on  TacPlot. 

17.  Link  1 1  tracks  symbols  tire  repositioned  on  TacPlot. 

18.  Operator  disables  interface  to  Link  1 1  system  (Gotti  2.2.1). 
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19.  Operator  enables  interface  to  shoreline  database. 

20.  Operator  sends  map  request. 

21.  Shoreline  database  accepts  map  request. 

22.  Shoreline  database  sends  map  message. 

23.  TacPlot  displays  map. 

24.  Operator  generates  new  manual  track  (Goal  4.2.1). 

26.  TacPlot  displays  manual  track  symbol. 

27.  Manual  tracks  are  repositioned  or  updated  on  TacPlot. 

25.  Operator  updates  position  of  a  track  (Goal  4.2.2. 1). 

26.  Tacplot  displays  updated  track  at  new  position  with  new  course  and  speed. 

26.  Operator  repositions  a  track  (Goal  4. 2. 2. 2). 

27.  TacPlot  displays  repositioned  track  at  new  position  with  old  course  and 
speed. 

28.  Operator  enters  new  course  and  speed  for  a  track.  (Goal  4.2. 3.2). 

29.  TacPlot  displays  track  at  old  position  with  new  course  and  speed. 

30.  Operator  terminates  a  track  (Goal  4. 2. 7. 2). 

31.  The  selected  track  is  not  anymore  displayed  on  the  TacPlot. 

32.  Operator  changes  category  of  a  track  (Goal  4.3. 1.2). 

33.  TacPlot  displays  track  symbol  with  changed  category. 

34.  Operator  changes  track  identity  (  Goal  4. 3. 2. 2). 

35.  TacPlot  displays  track  symbol  with  changed  identity. 

36.  Operator  changes  range  of  TacPlot. 
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37.  The  picture  of  the  current  situation  is  updated  according  to  the  range 
selected. 

38.  The  operator  hooks  a  position  on  the  Tacplot. 

39.  The  operator  is  requested  to  generate  a  new  track  or  special  point  when 
neither  of  the  current  tracks  is  at  the  hooked  position. 

40.  Additional  information  is  shown/further  action  requested  when  an  already 
existing  track  is  at  the  hooked  position. 

B.  The  Behavioral  Model 

The  Behavioral  model  describes  the  internal  behavior  required  of  the  system  to 
satisfactorily  interact  with  the  external  world.  For  the  purposes  of  this  research,  only 
the  data  flows,  data  structures  and  data  dictionary  for  the  LCCDS  are  defined.  We 
used  a  CASE  tool,  Software  Through  Pictures,  which  supports  the  Yourdon  model 
and  associated  symbology  to  create  the  above  mentioned  components  of  the 
Behavioral  model. 

1.  Data  Flow  Diagrams 

Data  flow  diagrams  are  commonly  used  systems  modeling  tools  whose 
purpose  "is  to  graphically  describe  a  system  as  a  group  of  functions,  processes  or 
objects  in  a  network  configuration  related  by  "data  flows"  connecting  the  various 
processes  to  each  other  he  external  world.  The  data  flow  diagram,  however, 
presents  only  one  perspective  of  the  system,  its  functions  and  their  associated  data 
objects.  Data  flow  diagrams,  or  DFD’s,  cover  a  large  range  of  system  detail,  from  the 
high  level  concepts,  to  low  level  processes  and  system  internal  architecture.  We 
provide  the  first  two  levels,  Level  Top  and  Level  Zero. 
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Level  Top  is  more  detailed  version  of  the  Context  diagram  (see  Figure  29).  It 
includes  a  description  of  the  data  objects  which  must  pass  between  LCCDS  and  the 
external  environment.  Level  Zero  (Figure  30)  is  one  level  of  detail  lower,  explaining 
the  major  system  processes  and  data  objects  necessary  for  supporting  LCCDSWS 
functionality. 
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Figure  29:  The  Top  Level  Diagram 
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Figure  30:  Level  Zero  Data  Flow  Diagram 


2.  Data  Structure  Diagrams 

Hierarchical  data  structure  diagrams  are  used  to  decompose  data  flows  and 
data  stores  defined  in  the  data  flow  diagram.  Data  structure  diagrams  allow  users  to 
view  the  system  from  a  "data”  perspective.  For  this  reason  we  provide  in  the 
following  the  data  structures  for  the  level  0  data  flow  diagram  as  generated  with  the 
Data  Structure  Editor  (DSE)  of  Software  through  Pictures  (StP).  DSE  is  an 
interactive  graphical  tool  for  drawing  data  structures.  It  can  generate  declarations  for 
C,  Ada,  and  Pascal,  as  well  as  input  to  the  StP  Data  Dictionary  system  (provided  by 
the  next  section).  StP  generated  all  the  data  structure  diagrams  provided  in  the 
following  series  of  figures  (Figures  31  -  69). 


Figure  31:  Data  Structure  Diagram  -  Additional  Tracklnfo 


These  diagrams  are  crucial  for  clear  definition  of  the  data  flows  depicted  in 
Figures  29  and  30.  They  represent  high  level  objects,  and  structures  of  objects.  Each 
data  structure  provided  in  each  figure  directly  corresponds  to  a  data  flow  or  a 
component  of  a  data  flow  of  the  Top  or  Zero  level  data  flow  diagrams  shown  in 
Figures  29  and  30.  For  ease  of  reference  the  diagrams  are  given  in  alphabetical  order. 
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Figure  32:  Data  Structure  Diagram  -  CPA  Data 


Figure  33:  Data  Structure  Diagram  -  CPA_Request 
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Figure  35:  Data  Structure  Diagram  -  Geographic  Position 
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Figure  38:  Data  Structure  Diagram  -  Linkll_Enable 
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LinkTracldnfo 


Figure  40:  Data  Structure  Diagram  -  LinkTracklnfo 


Figure  41:  Data  Structure  Diagram  -  Load_Map 
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Figure  42:  Data  Structure  Diagram  -  Longitude 
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Figure  44:  Data  Structure  Diagram  -  Map  Data 


Figure  45:  Data  Structure  Diagram  -  Map_Messages 
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Figure  48:  Data  Structure  Diagram  -  NavEnable 
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Figure  57:  Data  Structure  Diagram  ■  Range_SeIect 
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Figure  59:  Data  Structure  Diagram  -  System  lnitData 
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Figure  60:  Data  Structure  Diagram  -  SystemMessages 


Figure  61:  Data  Structure  Diagram  -  System_T racks 
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Figure  62:  Data  Structure  Diagram  -  TacInfo  AIpha 
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Figure  69:  Data  Structure  Diagram  •  Vehicular  Tracks 
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Further  definition  and  low  level  information  regarding  data  types  and  units  of 
measure  are  provided  in  the  next  section  as  part  of  the  Data  Dictionary.  Each 
individual  block  representing  a  data  element  in  the  data  structure  diagrams  is  fully 
defined  in  the  Data  Dictionary. 

3.  Data  Dictionary 

The  Data  Dictionary  is  probably  the  most  crucial  element  of  the  Behavioral 
model.  It  is  an  organized  listing  of  all  the  data  elements  that  are  pertinent  to  the 
system,  with  precise,  rigorous  definitions  so  that  both  user  and  systems  analyst  will 
have  a  common  understanding  of  all  inputs,  outputs,  components  of  data  stores,  and 
intermediate  calculations  [Ref.  18:p.  189).  The  data  dictionary  explains  the  meaning 
of  the  flows  between  processes,  composition  of  the  data  objects  and  values  and  units 
used  in  their  definition. 

A  full  listing  of  all  data  objects,  and  their  component  parts,  which  appear  in  the 
Top  and  Zero  DFDs  are  provided  in  alphabetical  order: 


133 


Name:  Add_Waypoint 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Request’ 

2  Components: 

Steaming_Route_ID  Data  Element 

Waypoint_Data  Sequence 

Used  in  1  Data  Structure 
Waypoint_Operation 

Name:  Additional_Special_Point_Info 
Defined  as  Data  Element  in  Data  Structure  Diagram  ’Special_Points’ 

Used  in  1  Data  Structure 
Special_Points 

Note  DataDefinition 

Name:  Additional_Special_Point_Info 
Type:  string 

Text  field  for  operator  use. 

Name:  Additional  Tracklnfo 

Defined  as  Sequence  in  Data  Structure  Diagram  ’AdditionaMTracklnfo’ 

3  Components: 

TrackType  Data  Element 

Hull_No  Data  Element 

i* 

Name  Data  Element 

Used  in  4  Data  Structures 
Manual_Tracks 
LinkTracklnfo 
Display_Track 
Tracks 
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Name:  Band 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Info’ 

Used  in  1  Data  Structure 
Radar_Info 

Note  DataDefinition 
Constraint:  A..Z 
Name:  Band 
Type:  character 

Indicates  the  band  of  the  selected  radar.  Band  indicator  as 
specified  by  current  EW  policy.  Preset  A..Z. 

Name:  Bearing 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Manual_Tracks’ 

Used  in  2  Data  Structures 
ManualJTracks 
Track_Data 

Note  DataDefinition 

Constraint:  000.00.. 359.00 
Name:  Bearing 
Type:  real 
Unit:  degrees 


>(ame:  CPAData 

Defined  as  Sequence  in  Data  Structure  Diagram  ’CPA_Data’ 


4  Components: 
Origin_Unit 
Time_To_CPA 
TrueBearing 
CPA_Distance 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 


Data  Element 
Data  Element 
Data  Element 
Data  Element 


3  Navigation_Handler 
1  MMI 
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Name:  CPA_Distance 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’CPA_Data’ 

Used  in  1  Data  Structure 
CPA_Data 

Note  DataDefinition 

Constraint:  00000.. 99999 
Name:  CPA_Distance 
Type:  integer 
Units:  yards 

Name:  CPA  Other  Track 

Defined  as  Sequence  in  Data  Structure  Diagram  ’CPA_Requesf 
2  Components: 

Origin_Track  Sequence 

Target_Track  Sequence 

Used  in  1  Data  Structure 
CPA_Selector 

Note  DataDefinition 

Name:  CPA_Other_Track 

CPA  Other  Track  requests  CPA  information  on  a  selected 
Origin  track  (other  than  ownship)  relative  to  a  second 
selected  Target  track. 

* 

Name:  CPA_Ownship 

Defined  as  Sequence  in  Data  Structure  Diagram  ’CPA_Requesf 
1  Component: 

Track_Data  Sequence 

Used  in  1  Data  Structure 
CPA_Selector 

Note  DataDefinition 
Name:  CPA_Ownship 

CPA  Ownship  requests  CPA  information  on  a  selected  track 
relative  to  ownship  position,  course  and  speed. 
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Name:  CPA_Request 

Defined  as  Selection  in  Data  Structure  Diagram  ’CPA_Request’ 

1  Component: 

CPAJSelector  Sequence 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 

Name:  CPA_Selector 
Defined  as  Sequence  in  Data  Structure  Diagram  ’CPA_Requesf 

2  Components: 

CPA_Ownship  Sequence 

CPA_Other_Track  Sequence 

Used  in  1  Data  Structure 
CPAJRequest 

Name:  Category 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’LinkTracklnfo’ 

Used  in  3  Data  Structures 
Manual_Tracks 
„  LinkTracklnfo 
Display_Track 

Note  DataDefinition 

Constraint:  Air  I  Surface  I  Subsurface 
Name:  Category 
Type:  string 


1  MMI 

3  Navigation_Handler 
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Name:  Command 


Used  in  1  Data  Structure 
Operator_Commands 

Note  DataDefinition 
Name:  Command 

Commands  are  generated  by  the  "hook"  function  or  by  menu 
selection,  in  any  order.  Hooking  a  point  on  any  active  TacPlot  shall 
cause  the  system  to  respond  depending  on  what,  if  anything,  was 
hooked.  This  may  include  prompts  and  menu  actions.  Making  a 
menu  selection  shall  cause  the  system  to  respond  in  some  way  as 
well,  including  prompting  the  user  to  hook  an  appropriate  point  for 
further  program  action. 

Name:  ContactID 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Tracks’ 

Used  in  1  Data  Structure 
Radar_Track 

Note  DataDefinition 
Constraint:  0000.. 9999 
Name:  ContactID 
Type:  integer 

Name:  Course 

'Defined  as  Data  Element  in  Data  Structure  Diagram 

’Navigational_Messages’ 

Used  in  5  Data  Structures 
Manual_Tracks 
Ownship 

Navigational_Message 

LinkTracklnfo 

Track_Data 

Note  DataDefinition 

Constraint:  000.00.. 359. 00 
Name:  Course 
Type:  real 
Unit :  degrees 
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Name:  DLRP 


Defined  as  Sequence  in  Data  Structure  Diagram  ’System_InitData’ 

1  Component: 

Geographic_Position  Sequence 

Used  in  1  Data  Structure 
System_InitData 

Name:  DeleteWaypoint 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Request’ 

2  Components: 

Steaming_Route_ID  Data  Element 

Waypoint_ID  Data  Element 

Used  in  1  Data  Structure 
Way  poi  n  t_Operation 

Name:  Display  Track 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Display_Tracks’ 

4  Components: 

Track_Data  Sequence 

Category  Data  Element 

Identity  Data  Element 

Additional_TrackInfo  Sequence 

Used  in  1  Data  Structure 
Display  _Tracks 
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Name:  DisplayT racks 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Display_Tracks’ 

1  Component: 

Display_Track 
Used  in  1  Data  Flow 
*  DFD  Level  From/To 
0  Process 
Process 

Note  DataDefinition 

Name:  Display_Tracks 
Stream  of  tracks  which  qualify  for  output. 

Name:  DisplayWaypoint 

Defined  as  Sequence  in  Data  Structure  Diagram  ’WaypointJRequesf 

2  Components: 

Steaming_Route_ID  Data  Element 

Waypoint_ID  Data  Element 

Used  in  1  Data  Structure 
Waypoint_Operation 

Name:  Distance 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Manual_Tracks’ 

Used  in  3  Data  Structures 
Manual_Tracks 
Waypoint_Data 
Track_Data 

Note  DataDefinition 

Constraint:  000.0..999.9 
Name:  Distance 
Type:  real 
Unit:  nautical  miles 


Sequence 


6  Tactical_DBMS 
1  MMI 
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Name:  ETA 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Data’ 

1  Component: 

Time  Sequence 

Used  in  1  Data  Structure 
Waypoint_Data 

Name:  ETE 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Data’ 

1  Component: 

Time  Sequence 

Used  in  1  Data  Structure 
Waypoint_Data 

Name:  FaultID 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Info’ 

Used  in  1  Data  Structure 
Faults 

Note  DataDefinition 
Constraint:  00..99 
Name:  Fault_ID 
Type:  integer 

Name:  Faults 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Radar_Info’ 

1  Component: 

Fault_ID  Data  Element 

Used  in  1  Data  Structure 
Radar_Info 

Note  DataDefinition 
Name:  Faults 

Indicates  faults  in  the  selected  radar.  Complete  when  radar 
interface  is  specified. 


141 


Name:  GeographicPosition 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Geographic_Position’ 


2  Components: 

Latitude  Sequence 

Longitude  Sequence 

Used  in  10  Data  Structures 
Map_Positions 
Map_Request 
Manual_Tracks 
Ownship 

Navigational_Message 
LinkTracklnfo 
Linkl  l_Track 
Track_Data 
DLRP 

Ownship_Position 
Name:  Hours 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Time’ 

Used  in  1  Data  Structure 
Time 

Note  DataDefinition 
Constraint:  00. .23 

l* 

Name:  Hours 
Type:  integer 

Name:  Hull_No 

Defined  as  Data  Element  in  Data  Structure 
’AdditionaLTracklnfo’ 

Used  in  1  Data  Structure 
AdditionaLTracklnfo 

Note  DataDefinition 
Name:  Hull_No 
Type:  string 


Diagram 
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Name:  Identity 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’LinkTracklnfo’ 

Used  in  3  Data  Structures 
Manual_Tracks 
LinkTracklnfo 
Display_Track 

Note  DataDefinition 

Constraint:  Friendly  I  Hostile  I  Unknown 
Name:  Identity 
Type:  string 

Name:  Julian  Date 

Defined  as  Data  Element  in  Data  Structure  Diagram 
’System_InitData’ 

Used  in  ;  Data  Structure 
System_InitData 

Note  DataDefinition 

Constraint:  0001. .9365 
Name:  Julian_Date 
Type:  integer 

Julian  date  is  simply  the  last  digit  of  the  current  year  followed  by 
the  day  represented  as  a  three  digit  integer  which  corresponds  to  a 
sequential  count  beginning  on  1  January. 
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Name:  LCCDSWS 


Defined  as  Process  in  Data  Flow  Diagram  ’top’ 

Process  index: 0 

6  Incoming  Parameters 
Linkl  l_Tracks 
Map_Messages 
Navigational_Messages 
Operator_Commands 
Operator_Messages 
Radar_Tracks 

4  Outgoing  Parameters 
Load_Map 
System_Messages 
TacInfo_Alpha 
TacInfo_Graphic 

Name:  LatDec 

Defined  as  Data  Element  in  Data  Structure  Diagram 

’Geographic_Position’ 

Used  in  1  Data  Structure 
Latitude 

Note  DataDefinition 
*  Constraint:  N  I  S 
Name:  LatDec 
Type:  character 


Data  Parameter 
Data  Parameter 
Data  Parameter 
Data  Parameter 


Data  Parameter 
Data  Parameter 
Data  Parameter 
Data  Parameter 
Data  Parameter 
Data  Parameter 
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Name:  LatDegrees 

Defined  as  Data  Element  in  Data  Structure  Diagram 
’Geographic_Position’ 

Used  in  2  Data  Structures 
Load_Map 
Latitude 

Note  DataDefinition 
Constraint:  00..90 
Name:  LatDegrees 
Type:  integer 
Unit:  degrees 

Name:  Latitude 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Geographic_Position’ 

4  Components: 

LatDegrees 
Minutes 
Seconds 
LatDec 

Used  in  1  Data  Structure 
Geographic_Position 

l\ame:  Link 

Defined  in  Data  Structure  Diagram  ’Link’ 

2  Components: 

Linkl  l_On/Off  Data  Element 

Linkl  l_Faults  Data  Element 

Used  in  1  Data  Structure 
Track_Status 


Data  Element 
Data  Element 
Data  Element 
Data  Element 
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Name:  LinkllEnable 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Linkl  l_Enable’ 

1  Component: 

Linkl  l_On/Off  Data  Element 

Used  in  1  Data  Flow 
DFD  Level  From/To 

0  Process  1  MMI 

Process  2  Track_Handler 

Name:  Linkl l  Faults 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Link’ 

Used  in  1  Data  Structure 
Link 

Note  DataDefinition 
Constraint:  00..99 
Name:  Linkl  l_Faults 
Type:  integer 

Used  for  later  implementation  of  link  fault  indication. 

Name:  Linkll_On/Off 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Linkl  l_Enable’ 

'Used  in  2  Data  Structures 
Linkl  l_Enable 
Link 

Note  DataDefinition 

Name:  Linkl  l_On/Off 
Type:  boolean 

Activates  task  in  track  handler  to  accept  Linkl  1  tracks  for 
processing. 
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Name:  Linkll_System 

Defined  as  External  in  Data  Flow  Diagram  ’top’ 

External  Id:  d 

Name:  Link  11_T rack 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Linkl  l_Tracks’ 

4  Components: 

Time 

Geographic_Position 
Participating_Unit 
LinkTracklnfo 

Used  in  1  Data  Structure 
Linkl l_Tracks 

Name:  Linkl  ITracks 
Defined  as  Iteration  in  Data  Structure  Diagram  ’Linkl  lJTracks’ 

1  Component: 

Linkl l_Track  Sequence 

Used  in  2  Data  Flows 
DFD  Level  From/To 

top  External  (d)  Linkl  l_System 

,  Process  0  LCCDSWS 

0  Offpage  Level  0 

Process  2  Track_Handler 


Sequence 
Sequence 
Data  Element 
Sequence 
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Name:  LinkTracklnfo 

Defined  as  Sequence  in  Data  Structure  Diagram  ’LinkTracklnfo’ 

7  Components: 

Category 
Identity 
Course 
Speed 
Time 

Geographic_Position 
AdditionaLTracklnfo 

Used  in  1  Data  Structure 
Linkll_Track 

Name:  Load  Map 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Load_Map’ 

2  Components: 

LatDegrees  Data  Element 

LongDegrees  Data  Element 

Used  in  2  Data  Flows 
DFD  Level  From/To 
top  Process 
External 
0  Process 

Offpage  Level  0 

Note  DataDefinition 
Name:  Load_Map 
The  Load_Map  datastructure  is  defined  in  terms  of  DMA  map 
data-management.  Each  map  chunk  corresponds  to  one  degree 
(60min  Lat  by  60min  Long)  of  the  earth  surface. 


0  LCCDSWS 

(c)  Shoreline_Database 

4  Map_Handler 


Data  Element 
Data  Element 
Data  Element 
Data  Element 
Sequence 
Sequence 
Sequence 
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Name:  LongDec 

Defined  as  Data  Element  in  Data  Structure  Diagram 

’Geographic_Position  ’ 

Used  in  1  Data  Structure 
Longitude 

Note  DataDefinition 
Constraint:  E  I  W 
Name:  LongDec 
Type:  character 

Name:  LongDegrees 

Defined  as  Data  Element  in  Data  Structure  Diagram 

’Geographic_Position  ’ 

Used  in  2  Data  Structures 
Load_Map 
Longitude 

Note  DataDefinition 
Constraint:  000..  179 
Name:  LongDegrees 
Type:  integer 
Unit:  degrees 


Name:  Longitude 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Geographic_Position’ 


4  Components: 
LongDegrees 
Minutes 
Seconds 
LongDec 

Used  in  1  Data  Structure 
Geographic_Position 

Note  DataDefinition 
Name:  Longitude 


Data  Element 
Data  Element 
Data  Element 
Data  Element 
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Name:  MMI 


Defined  as  Process  in  Data  Flow  Diagram  ’0’ 
Process  index:  1 


8  Incoming  Parameters 


CPA_Data 

Data  Parameter 

Display  _Tracks 

Data  Parameter 

Map_Data 

Data  Parameter 

Navigation_Data 

Data  Parameter 

Operator_Commands 

Data  Parameter 

Operator_Messages 

Data  Parameter 

Track_Status 

Data  Parameter 

Waypoint_Data 

Data  Parameter 

14  Outgoing  Parameters 

CPA_Request 

Data  Parameter 

Linkll_Enable 

Data  Parameter 

Manual  Tracks 

Data  Parameter 

Map_Request 

Data  Parameter 

NavStatus 

Data  Parameter 

Nav_Enable 

Data  Parameter 

Radar_Enable 

Data  Parameter 

Range_Select 

Data  Parameter 

SpeciaLPoints 

Data  Parameter 

System_InitData 

Data  Parameter 

System_Messages 

Data  Parameter 

TacInfo_Alpha 

Data  Parameter 

TacInfo_Graphic 

Data  Parameter 

Waypoint_Request 

Data  Parameter 
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Name:  Manual_T racks 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Manual_Tracks’ 


9  Components: 

Category 

Data  Element 

Identity 

Data  Element 

Bearing 

Data  Element 

Distance 

Data  Element 

Geographic_Position 

Sequence 

Course 

Data  Element 

Speed 

Data  Element 

Time 

Sequence 

Additional_TrackInfo 

Sequence 

Used  in  1  Data  I  low 

DFD  Level  From/To 

0  Process 

1  MMI 

Process 

2  Track_Handler 

Name:  MapData 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Map. 

2  Components: 

Map_Number 

Data  Element 

Map_Positions 

Iteration 

,Used  in  1  Data  Flow 

DFD  Level  From/To 

0  Process 

4  Map_Handler 

Process 

1  MMI 
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Name:  Map_Handler 

Defined  as  Process  in  Data  Flow  Diagram  ’0’ 

Process  index: 4 


2  Incoming  Parameters 
Map_Messages 
Map_Request 

2  Outgoing  Parameters 
Load_Map 
Map_Data 


Data  Parameter 
Data  Parameter 


Data  Parameter 
Data  Parameter 


Name:  Map_Messages 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Map_Messages’ 


2  Components: 

Map_Number  Data  Element 

Map_Positions  Iteration 


Used  in  2  Data  Flows 
DFD  Level  From/To 

top  External  (c)  Shoreline_Database 

Process  0  LCCDSWS 

0  Offpage  Level  0 

Process  4  Map_Handler 


Name:  Map  Number 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Map_Messages’ 

Used  in  2  Data  Structures 
Map_Messages 
Map_Data 

Note  DataDefinition 

Constraint:  0000..9999 
Name:  Map_Number 
Type:  integer 
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Name:  Map_Positions 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Map_Messages’ 

1  Component: 

Geographic_Position  Sequence 

Used  in  2  Data  Structures 
Map_Messages 
Map_Data 

Name:  Map  Request 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Map_Request’ 

1  Component: 

Geographic_Position  Sequence 

Used  in  1  Data  Flow 
DFD  Level  From/To 

0  Process  1  MMI 

Process  4  Map_Handler 

Name:  Message 

Note  DataDefinition 
Name:  Message 

A  message  consists  of  data  the  system  must  obtain 
from  the  operator. 

The  system  shall  prompt  the  user  for  required  information  based  on 
currently  active  commands  and  processes.  The  information  shall 
be  provided  via  menu  selection  process,  data  entry  into  system 
generated  Forms  and  templates,  etc. 
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Name:  Minutes 

Defined  as  Data  Element  in  Data  Structure  Diagram 

’Geographic_Position’ 

Used  in  3  Data  Structures 
Time 
Latitude 
Longitude 

Note  DataDefinition 
Constraint:  00. .59 
Name:  Minutes 
Type:  integer 
Unit:  minutes 

Name:  Mode 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Info’ 

Used  in  1  Data  Structure 
Radarjnfo 

Note  DataDefinition 

Constraint:  MTIINon-MTIISurface 
Name:  Mode 
Type:  string 

The  indicated  modes  are  assumptions  and  have  to  be  adapted 
„  when  radar  interface  is  specified. 

Name:  Name 

Defined  as  Data  Element  in  Data  Structure  Diagram 

’AdditionaLTracklnfo’ 

Used  in  1  Data  Structure 
AdditionaLTracklnfo 

Note  DataDefinition 
Name:  Name 
Type:  string 
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Name:  NavStatus 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’NavStatus’ 

Used  in  2  Data  Structures 
Navigational_Message 
Navigation_Data 

Used  in  1  Data  Flow 
DFD  Level  From/To 

0  Process  1  MMI 

Process  6  Tactical_D3MS 

Note  DataDefinition 
Name:  NavStatus 
Type:  boolean 

At  this  time  NavStatus  does  not  contain  information  about  the 
subsystems  of  the  Navigational  Systems.  These  have  to  be 

defined  at  a  later  time  and  will  need  a  fault  indicator  for  LCCDSWS. 

Name:  NavEnable 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Nav_EnabIe’ 

Used  in  1  Data  Flow 
DFD  Level  From/To 

0  Process  1  MMI 

Process  3  Navigation_Handler 

,  Note  DataDefinition 
Name:  Nav_Enable 
Type:  boolean 

True  =  Navigational  Messages  are  accepted  by  the  Navigation 
Handler. 

False  =  Navigational  Messages  are  ignored  by  the  Navigation 
Handler.  Ownship  no  longer  updated  from  external  source. 
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Name:  Navigation_Data 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Navigation_Data’ 


2  Components: 

Ownship 

NavStatus 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 


Sequence 
Data  Element 


3  Navigation_Handler 
1  MMI 


Name:  Navigation_Handler 
Defined  as  Process  in  Data  Flow  Diagram  ’O’ 

Process  index:  3 


5  Incoming  Parameters 


CPA_Request 

Data  Parameter 

Nav_Enable 

Data  Parameter 

NavigationaLMessages 

Data  Parameter 

SystemJmtData 

Data  Parameter 

Waypoint„Request 

Data  Parameter 

4  Outgoing  Parameters 

CPA_Data 

Data  Parameter 

Navigation_Data 

Data  Parameter 

„  Ownship 

Data  Parameter 

Waypoint_Data 

Data  Parameter 

Name:  Navigation_System 

Defined  as  External  in  Data  Flow  Diagram  ’top’ 

External  Id:  a 
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Name:  NavigationalMessage 
Defined  as  Sequence  in  Data  Structure 
’NavigationaLMessages’ 

5  Components: 

Geographic_Position 
Course 
Speed 
Time 
NavStatus 

Used  in  1  Data  Structure 
NavigationaLMessages 

Note  DataDefinition 

Name:  Navigational_Message 

Name:  NavigationaLMessages 

Defined  as  Iteration 
’NavigationaLMessages’ 

1  Component: 

NavigationaLMessage 

Used  in  2  Data  Flows 
DFD  Level  From/To 
top  External 
Process 

0  Offpage  Level  0 
Process 

Name:  Offpage.O 

Defined  as  Offpage  Connector  in  Data  Flow  Diagram  ’0’ 

Name:  Offpage.top 

Defined  as  Offpage  Connector  in  Data  Flow  Diagram  ’top’ 


in  Data  Structure 

Sequence 

(a)  Navigation_System 
0  LCCDSWS 

3  Navigation_Handler 


Sequence 
Data  Element 
Data  Element 
Sequence 
Data  Element 


Diagram 


Diagram 
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Name:  Operator 

Defined  as  External  in  Data  Flow  Diagram  ’top’ 

External  Id:  e 

Name:  Operator  Commands 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Operator_Commands’ 

1  Component: 

Command 

Used  in  2  Data  Flows 

DFD  Level  From/To 
top  External 
Process 

0  Offpage  Level  0 
Process 

Name:  Operator  Message 

Defined  as  Undefined  Data 

Used  in  1  Data  Structure 
Operator_Messages 

Note  DataDefinition 

Name:  Operator_Message 
„  A  message  consists  of  data  the  system  must  obtain  from  the 
operator.  The  system  shall  prompt  the  user  for  required 
information  based  on  currently  active  commands  and 
processes.  The  information  shall  be  provided  via  menu 
selection  process,  data  entry  into  system  generated  forms  and 
templates,  etc. 


(e)  Operator 
0  LCCDSWS 

1  MMI 
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Name:  Operator_Messages 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Operator_Messages’ 


1  Component: 

Operator_Message  Undefined  Data 


Used  in  2  Data  Flows 
DFD  Level  From/To 
top  External 
Process 

0  Offpage  Level  0 
Process 


(e)  Operator 
0  LCCDSWS 

1  MMI 


Name:  Origin 

Defined  as  Data  Element  in  Data  Structure  Diagram 
’System_Tracks’ 

Used  in  1  Data  Structure 
Tracks 

Note  DataDefinition 

Constraint:  Local  Manual  I  Local  Auto  I  Remote 
Name:  Origin 
Type:  string 

Indicates  source  of  track  data: 

Local  Manual:  Operator, 

Local  Auto:  Radar, 

Remote:  Linkl  1. 

Name:  Origin_Track 

Defined  as  Sequence  in  Data  Structure  Diagram  ’CPA_Request’ 

1  Component: 

Track_Data  Sequence 

Used  in  1  Data  Structure 
CPA_Other_Track 
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Name:  Origin_Unit 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’CPA_Data’ 

Used  in  1  Data  Structure 
CPA_Data 

Note  DataDefinition 

Constraint:  OwnUnit  I  OriginTrack 
Name:  Origin_Unit 
Type:  string 


Name:  Ownship 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Ownship’ 


4  Components: 

Geographic_Position 

Course 

Speed 

Time 

Used  in  1  Data  Structure 
Navigation_Data 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 

Note  DataDefinition 
Name:  Ownship 


Sequence 
Data  Element 
Data  Element 
Sequence 


3  Navigation_Handler 
2  Track_Handler 


Name:  Ownship  Position 

Defined  as  Sequence  in  Data  Structure  Diagram  ’System_InitData’ 
1  Component: 

Geographic_Position  Sequence 

Used  in  1  Data  Structure 
System_InitData 
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Name:  Participating_Unit 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Linkl  l_Tracks’ 

Used  in  1  Data  Structure 
Linkl  l_Track 

Note  DataDefinition 
Constraint:  00. .76 
Name:  Participating_Unit 
Type:  integer 

Octal  Number  representing  Link  1 1  participating  units. 

Name:  Radar 

Defined  as  Sequence  in  Data  Structure  Diagram  ’TrackJJtatus’ 

3  Components: 

RadarJD 
Range 
Radarjnfo 

Used  in  1  Data  Structure 
Track_Status 

Name:  Radar_Enable 

Defined  as  Sequence  in  Data  Structure  Diagram  ’RadarJBnable’ 

2  Components: 

RadarJD 
Radar_On/Off 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 

Note  DataDefinition 
Name:  RadarJEnable 
Activates  tasks  in  track  handler  to  accept  tasks  for  processing  of 
tracks  from  the  selected  radar  identified  by  RadarJD.  RadarJD 
shall  set  to  the  range  of  radars  available,  preset  0..9. 


Data  Element 
Data  Element 


1  MMI 

2  Trackjdandler 


Data  Element 
Data  Element 
Sequence 
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Name:  RadarlD 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Enable’ 

Used  in  2  Data  Structures 
Radar_Enable 
Radar 

Note  DataDefinition 
Constraint:  0..9 
Name:  Radar_ID 
Type:  integer 

Identifies  the  selected  radar. 

Name:  Radar  lnfo 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Radarjnfo’ 

4  Components: 

Mode 
Standby 
Faults 
Band 

Used  in  1  Data  Structure 
Radar 

Note  DataDefinition 
Name:  Radar_Info 

'  Radarjnfo  will  held  additional  informations  about  the  status  of  the 
selected  radar  e.g.,  mode,  faults,  band,  transmitter  on/off. 

Has  to  be  determined  completely  when  radar  interface  is  fully 
specified. 


Data  Element 
Data  Element 
Iteration 
Data  Element 
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Name:  Radar_On/Off 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Enable’ 

Used  in  1  Data  Structure 
Radar_Enable 

Note  DataDefinition 
Name:  Radar_On/Off 
Type:  boolean 
true  =  radar  on 
false  =  radar  off. 

Name:  Radar_System 

Defined  as  External  in  Data  Flow  Diagram  ’top’ 

External  Id:  b 

Name:  Radar  Track 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Radar_Tracks’ 

3  Components: 

Range 

TrueBearing 
ContactID 

Used  in  1  Data  Structure 
„  Radar_Tracks 

Name:  Radar  T racks 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Radar_Tracks’ 

1  Component: 

Radar_Track  Sequence 

Used  in  2  Data  Flows 
DFD  Level  From/To 

top  External  (b)  Radar_System 

Process  0  LCCDSWS 

0  Offpage  Level  0 

Process  2  Track_Handler 


Data  Element 
Data  Element 
Data  Element 
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Name:  Range 

Defined  as  Data  Element  in  Data  Structure  Diagram  Radar_Tracks’ 

Used  in  2  Data  Structures 
Radar_Track 
Radar 

Note  DataDefinition 

Constraint:  000.0.. 999. 9 
Name:  Range 
Type:  real 

Unit :  Nautical  Miles 
Name:  Range_Select 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Range_Select’ 

Used  in  1  Data  Flow 

DFD  Level  From/To 

0  Process  1  MMI 

Process  6  Tactical_DBMS 

Note  DataDefinition 

Constraint:  2141811 61321641 1 28125615 1 2 
Name:  RangejSelect 
Type:  integer 

Name:  Seconds 

Defined  as  Data  Element  in  Data  Structure  Diagram 

’Geographic_Position  ’ 

Used  in  3  Data  Structures 
Time 
Latitude 
Longitude 

Note  DataDefinition 
Constraint:  00.. 59 
Name:  Seconds 
Type:  integer 
Unit:  seconds 
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Name:  Shoreline_Database 

Defined  as  External  in  Data  Flow  Diagram  ’top’ 

External  Id:  e 

Name:  Special_Point_Category 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’SpeciaLPoints’ 

Used  in  1  Data  Structure 
Special_Points 

Note  DataDefinition 

Constraint:  Man  in  Water  I  Formation  Center  I  PIM  I  Nav  Hazard  I 
DL  RP  I  Reference  Point 
Name:  Special_Point_Category 
Type:  string 

Name:  Special_Points 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Special_Points’ 

3  Components: 

Special_Point_Category  Data  Element 

Track„Data  Sequence 

Additional_Special_Point_Info  Data  Element 

Used  in  1  Data  Flow 
,  DFD  Level  From/To 
0  Process 
Process 

Note  DataDefinition 
Name:  Special_Points 
All  Special  Points  have  certain  geographic  information  which  is 
passed  via  the  Track  Data  object.  In  some  cases  not  all  the  data 
contained  in  Track  Data  is  applicable.  For  instance,  only  the 
Formation  Center  and  PIM  special  points  have  course/speed  info 
associated  with  them. 


1  MMI 

2  Track  Handler 
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Name:  Speed 

Defined  as  Data  Element  in  Data  Structure  Diagram 
’Navigational_Messages’ 

Used  in  5  Data  Structures 
Manual_Tracks 
Ownship 

Navigational_Messages 

LinkTracklnfo 

Track_Data 

Note  DataDefinition 

Constraint:  000.0..999.9 
Name:  Speed 
Type:  real 
Unit :  knots 

Name:  Standby 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Info’ 

Used  in  1  Data  Structure 
Radar_Info 

Note  DataDefinition 
Name:  Standby 
Type:  boolean 

Indicates  whether  radar  is  transmitting  (false)  or  in  standby 
(true). 
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Name:  Steaming_Route_ID 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Waypoint_Data’ 

Used  in  5  Data  Structures 
Waypoint_Data 
Add_Waypoint 
Update_Waypoint 
Delete_Waypoint 
Display_Waypoint 

Note  DataDefinition 
Constraint:  1..6 
Name:  Steaming_Route_ID 
Type:  integer 


Name:  System_InitData 

Defined  as  Sequence  in  Data  Structure  Diagram  ’SysterrMnitData’ 


4  Components: 

DLRP 

O  w  n  sh  i  p_Pos  i  tion 

Julian__Date 

Time 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 


Sequence 
Sequence 
Data  Element 
Sequence 


1  MMI 

3  Navigation_Handler 


Name:  SystemMessage 

Used  in  1  Data  Structure 
System^Messages 

Note  DataDefinition 

Name:  System_Message 

Messages  shall  consist  of  structures  defining  the  information 
provided  to  the  user  by  the  system  including  prompts,  cues,  alerts, 
warnings,  help,  etc.  The  system  shall  generate  these  messages 
independently  or  as  a  result  of  operator  actions/commands. 
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Name:  System_Messages 

Defined  as  Iteration  in  Data  Structure  Diagram  ’System_Messages’ 
1  Component: 

System_Message  Undefined  Data 

Used  in  2  Data  Flows 
DFD  Level  From/To 
top  Process 
External 
0  Process 

Offpage  Level  0 

Name:  SystemT racks 

Defined  as  Iteration  in  Data  Structure  Diagram  ’SystemJTracks’ 

1  Component: 

Tracks  Sequence 

Used  in  1  Data  Flow 
DFD  Level  From/To 

0  Process  2  Track_Handler 

Process  6  Tactical_DBMS 

Name:  TacInfo  Alpha 

Defined  as  Iteration  in  Data  Structure  Diagram  ’TacInfo_Alpha’ 

»• 

1  Component: 

TacInfo_Tab)eau  Undefined  Data 

Used  in  2  Data  Flows 
DFD  Level  From/To 

top  Process  0  LCCDSWS 

External  (e)  Operator 

0  Process  1  MMI 

Offpage  Level  0 


0  LCCDSWS 
(e)  Operator 
1  MMI 
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Name:  TacInfo  Graphic 

Defined  as  Iteration  in  Data  Structure  Diagram  ’TacInfo_Graphic’ 
i  Component. 

TacInfo_Windows  Undefined  Data 

Used  in  2  Data  Flows 
DFD  Level  From/To 
top  Process 
External 
0  Process 

Offpage  Level  0 

Name:  TacInfo  Tableau 

Defined  as  Undefined  Data 

Used  in  1  Data  Structure 
TacInfo_Alpha 

Note  DataDefinition 

Name:  TacInfo_TabIeau 
Taclnfo  Tableaux  are  individual  structures  containing  a  set  of 
related  information  which  must  be  accessible  to  the  operator  in 
alphanumeric  form.  These  tableaux  shall  support  output  of  tactical 
data  and  information  as  well  as  user  data  input.  The  system  shall 
continuously  update  the  tableaux  as  information  they  display  is 
,  changed. 


0  LCCDSWS 
(e)  Operator 
1  MMI 
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Name:  TacInfo_Windows 
Defined  as  Undefined  Data 

Used  in  1  Data  Structure 
TacInfo_Graphic 

Note  DataDefinition 

Name:  TacInfo_Windows 

Taclnfo  Windows  provide  the  method  for  organization  of  the 
system  and  tactical  information  presentation  to  the  user.  Graphics 
and  graphical  data  are  displayed  within  the  structure  of  a  window 
environment.  This  environment  defines  the  Tactical  Display.  The 
basic  ingredients  of  the  Tactical  Display  are;  TacPlot  windows,  a 
system  of  menu  windows  and  Tableau  windows. 

Name:  Tactical_DBMS 
Defined  as  Process  in  Data  Flow  Diagram  ’0’ 

Process  index: 6 

4  Incoming  Parameters 
NavStatus 
Range_Select 
System_Tracks 
Vehicular_Tracks 

2  Outgoing  Parameters 
'  Display_Tracks 
Vehicular_Tracks 

Name:  Target_Track 

Defined  as  Sequence  in  Data  Structure  Diagram  ’CPA_Requesf 
1  Component: 

Track_Data  Sequence 

Used  in  1  Data  Structure 
CPA_Other_Track 


Data  Parameter 
Data  Parameter 
Data  Parameter 
Data  Parameter 

Data  Parameter 
Data  Parameter 
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Name:  Time 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Time’ 

4  Components: 

Hours 
Minutes 
Seconds 
TimeZone 

Used  in  9  Data  Structures 
ManuaLTracks 
Ownship 

Navigational_Messages 

LinkTracklnfo 

Linkl  l_Track 

Track_Data 

ETA 

ETE 

System_InitData 

Note  DataDefinition 
Name:  Time 

Name:  TimeZone 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Time’ 

Used  in  1  Data  Structure 

i» 

Time 

Note  DataDefinition 
Constraint:  A..Z 
Name:  TimeZone 
Type:  character 

Default  value  should  be  ’Z’  for  "zulu"  or  Universal  Coordinated 
Time. 


Data  Element 
Data  Element 
Data  Element 
Data  Element 
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Name:  Time_To_CPA 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’CPA_Data’ 

Used  in  1  Data  Structure 
CPA_Data 

Note  DataDefinition 
Constraint:  000.. 999 
Name:  Time_To_CPA 
Type:  integer 
Unit:  minutes 

Name:  TrackType 

Defined  as  Data  Element  in  Data  Structure 

’Additional_TrackInfo’ 

Used  in  1  Data  Structure 
Additional_TrackInfo 

Note  DataDefinition 
Name:  TrackType 
Type:  string 


* 


Diagram 
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Name:  Track_Data 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Track_Data’ 


7  Components: 


Track_Number 

Data  Element 

Geographic_Position 

Sequence 

Bearing 

Data  Element 

Distance 

Data  Element 

Time 

Sequence 

Course 

Data  Element 

Speed 

Data  Element 

Used  in  7  Data  Structures 

Special_Points 

Display_Track 

Vehicular_Track 

CPA_Ownship 

Origin_Track 

Target_Track 

Tracks 

Name:  Track_Handler 

Defined  as  Process  in  Data 

Flow  Diagram  ’0’ 

Process  index:  2 

7  Incoming  Parameters 

Linkl  l_Enable 

Data  Parameter 

Linkl  l_Tracks 

Data  Parameter 

ManuaLTracks 

Data  Parameter 

Ownship 

Data  Parameter 

Radar_Enable 

Data  Parameter 

Radar_Tracks 

Data  Parameter 

Special_Points 

Data  Parameter 

2  Outgoing  Parameters 

System_Tracks 

Data  Parameter 

Track_Status 

Data  Parameter 
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Name:  Track_Info 

Used  in  1  Data  Structure 
Tracks 

Name:  Track  Number 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Track_Data’ 

Used  in  1  Data  Structure 
Track_Data 

Note  DataDefinition 

Constraint:  0000..7776 
Name:  Track_Number 
Type:  integer 

Name:  Track_Status 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Track_Status’ 

2  Components: 

Radar 
Link 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 

•» 

Name:  Tracking  Filter 
Defined  as  Process  in  Data  Flow  Diagram  ’0’ 

Process  index:  5 

1  Incoming  Parameter 

Vehicular_Tracks  Data  Parameter 

1  Outgoing  Parameter 

Vehicular_Tracks  Data  Parameter 


Sequence 

Sequence 


2  Track_Handler 
1  MMI 
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Name:  Tracks 

Defined  as  Sequence  in  Data  Structure  Diagram  ’System_Tracks’ 

3  Components: 

Track_Data 
Additional_TrackInfo 
Origin 

Used  in  1  Data  Structure 
System_Tracks 

Name:  TrueBearing 
Defined  as  Data  Element  in  Data  Structure  Diagram  ’Radar_Tracks’ 

Used  in  3  Data  Structures 
CPA_Data 
Waypoint_Data 
Radar_Track 

Note  DataDefinition 

Constraint:  000 .00.. 999 .99 
Name:  TrueBearing 
Type:  real 
Unit:  degrees 

Name:  UpdateWaypoint 

'  Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Request’ 
3  Components: 

Steaming_Route_ID  Data  Element 

Waypoint_ID  Data  Element 

Waypoint_Data  Sequence 

Used  in  1  Data  Structure 
Waypoint_Operation 


Sequence 
Sequence 
Data  Element 
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Name:  VehicularTrack 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Vehicular_Tracks’ 
1  Component: 

Track_Data  Sequence 

Used  in  1  Data  Structure 
Vehicular_Tracks 

Name:  Vehicular_T racks 

Defined  as  Iteration  in  Data  Structure  Diagram  ’Vehicular_Tracks’ 

1  Component: 

Vehicular_Track  Sequence 

Used  in  2  Data  Flows 
DFD  Level  From/To 

0  Process  5  Tracking_Filter 

Process  6  Tactical_DBMS 

0  Process  6  TacticaLDBMS 

Process  5  Tracking_Filter 

Name:  WaypointData 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Data’ 

6  Components: 

»  Steaming_Route_ID 
WaypoinfJD 
TrueBearing 
Distance 
ETA 
ETE 

Used  in  2  Data  Structures 
Add_Waypoint 
Update_Waypoint 

Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 


3  Navigation_Handier 
1  MMI 


Data  Element 
Data  Element 
Data  Element 
Data  Element 
Sequence 
Sequence 
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Name:  WaypointID 

Defined  as  Data  Element  in  Data  Structure  Diagram  ’Waypoint_Data’ 

Used  in  4  Data  Structures 
Waypoint_Data 
Update_Waypoint 
Delete_Waypoint 
Display  _Way  point 

Note  DataDefinition 
Constraint:  1..50 
Name:  Waypoint_ID 
Type:  integer 

Name:  Waypoint  Operation 

Defined  as  Sequence  in  Data  Structure  Diagram  ’Waypoint_Requesf 

4  Components: 

Add_Waypoint 
UpdateJWaypoint 
Delete_Waypoint 
Display_Waypoint 

Used  in  1  Data  Structure 
Waypoint_Request 

Note  DataDefinition 

Name:  Waypoint_Operation 
Waypoint_Request  is  either  a: 

Add  Waypoint  or 
-Update_Waypoint, 

-Delete_Waypoint. 


Sequence 

Sequence 

Sequence 

Sequence 
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Name:  WaypointRequest 

Defined  as  Selection  in  Data  Structure  Diagram  ’Waypoint_Request’ 
1  Component: 

Waypoint_Operation  Sequence 

1  MMI 

3  Navigation_Handler 


Used  in  1  Data  Flow 
DFD  Level  From/To 
0  Process 
Process 
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IV.  MAN-MACHINE  INTERFACE  DESIGN  GUIDELINES 

During  the  requirements  analysis  for  the  LCCDSWS  it  became  obvious  that  the 
MM  I  would  be  one  of  the  most  important  components  of  the  proposed  software 
system.  Much  research  was  conducted  to  determine  the  issues  of  an  effective  user 
interface  in  a  tactical  environment.  We  intend  to  provide  an  MMI  for  the  LCCDS  that 
is  consistent  with  current  Navy  development  efforts  for  a  standardized  workstation 
interface  (Ref.  5].  The  outcome  of  this  research  is  included  in  Chapter  II  as  Goal  1, 
the  goal  hierarchy  for  the  MMI.  However,  it  seems  important  to  us  not  to  lose  the 
findings  of  the  research  carried  out  on  user  interface  issues.  For  this  reason  we  add 
this  chapter  to  the  LCCDSWS  requirements  analysis.  It  shall  provide  some  of  the 
underlying  ideas  for  further  design  and  implementation  of  the  MMI  as  specified  in 
Goal  1  and  represents  in  some  sense  an  environment  model  for  a  standardized  MMI 
software  system.  Recommendations  are  further  developed  based  on  ideas  and  inputs 
from  experienced  fleet  operators  and  Surface  Warfare  Officers  along  with  technology 
being  explored  at  the  Naval  Postgraduate  School,  the  various  Navy  systems 

i* 

commands  and  laboratory  facilities. 

A.  LCCDS  USER  CONCEPTUAL  MODEL 

The  single  most  important  ingredient  of  any  interactive  computer  system  is  the 
user  interface,  the  direct  connection  through  which  all  interaction  between  man  and 
machine  takes  place.  This  interface  is  often  the  critical  factor  in  the  success  or  failure 
of  a  system  {Ref.  19:p.  1  ]. 
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Before  the  design  of  a  man-machine  interface  with  even  a  modest  chance  for 
success  can  begin,  the  system  designers  must  have  a  thorough  understanding  of  the 
people  who  will  use  it.  A  user  model  must  be  developed.  The  user  model  is  an 
attempt  to  define  the  characteristics  and  attributes  associated  with  that  user,  or 
group  of  users,  which  will  play  a  large  part  in  the  perceptions  they  form  regarding  the 
performance  and  functional  utility  of  the  system.  The  user  interface  must  support  a 
high  level  concept  of  the  machine/system  that  the  user  can  understand  and  relate 
directly  to  the  tasks  he  must  perform. 

A  user  model  for  military  systems  can  be  fairly  straight-forward  to  develop. 
Much  of  the  model  can  be  abstracted  from  pre-existing  information  on  mission, 
tactical  doctrine,  terminology  and  training.  A  particular  user  can  be  roughly  described 
as  a  novice,  professional  or  expert  as  appropriate  to  his  skills  and  abilities  to  handle 
the  system.  For  our  purposes  it  is  sufficient  to  describe  a  user  by  the  events  that 
relate  the  real  world  environment  to  the  corresponding  tactical  decisions, 
recommendations  and  ensuing  actions  he  is  responsible  for: 

-  Recognition  of  the  information 

-  Interpreting  the  meaning  of  that  information 

-  Decision 

-  Reaction 

With  this  in  mind  the  following  assumptions  regarding  operators  of  the  LCCDS 
are  made: 

(1)  There  will  be  a  wide  spectrum  of  user  experience  and  ability  with  NTDS  and 
CDS  systems  ranging  from  the  newest  seaman  to  the  senior  petty  officer 
and  Chief  petty  officer  levels. 
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(2)  An  experienced  Watch  Supervisor  will  be  available  to  guide  and  assist  the 

newly  trained  operators. 

(3)  All  operators  will  have  a  basic  understanding  of  the  requirements  of  their 

particular  rating  to  include  the  following: 

-  basic  maneuvering  board  relationships 

-  navigation 

-  radar 

-  NTDS  symbology  and  terminology 

-  Navy  Standard  Operating  Procedures  (SOP)  for  ships  underway 

In  addition  to  the  military  training  and  experience  aspects  of  the  user  group,  the 
characteristics  and  capabilities  of  humans  in  general  must  be  acknowledged  and 
adapted  to  by  the  man-machine  interface.  Some  of  the  important  physiological  and 
psychological  factors  to  be  considered  are 

-  human  performance  will  degrade  over  time  due  to  fatigue,  boredom  or  attitude. 

-  visual  detail  is  obtained  over  a  narrow  range  (about  2  degrees)  of  eyesight 
[Ref.  20:p.  25]. 

-  aural/audio  communication  can  be  processed  by  a  human  faster  than  any  other 
method  [Ref.  19:p.  422]. 

-  effective  capacity  of  human  working  (short  term)  memory  is  limited  to  a  range 
of  5  to  9  different  things  ("chunks"  of  information)  [Ref.  20:p.  39]. 

With  an  awareness  of  these  important  cognitive  factors,  the  designer  must  create 
an  interface  which  will  reliably  perform  in  a  manner  expected  by  the  user.  The  users 
confidence  in  the  system  is  directly  related  to  how  well  the  interface  supports  his 
conceptual  model  of  what  ti  e  system  is  and  does.  The  users  conceptual  model  of  the 
LCCDS  is  expected  to  be  something  like  the  following: 

The  LCCDS  is  a  visual,  map-like  representation  of  a  portion  of  the 
Earth  upon  which  tactically  significant  tracks,  representing  real  world 
objects,  shall  be  imposed.  Tracks  shall  move  on  the  display  with  respect 


to  accurate  time  and  spatial  measurements  obtained  from  the  ships 
organic  sensors  (radar,  navigational,  visual,  ESM,  Link).  The  real  world 
objects  represented  on  the  LCCDS  display  shall  be  associated  with 
NTDS  standard  symbology  and  data. 

Through  the  use  of  menus,  cues,  alerts  and  data  tableaus  the  user 
shall  be  led  through  all  actions  involving  control  of  the  tactical  display  and 
be  allowed  to  manipulate  data  and  filter  information  in  a  manner 
consistent  with  mission  requirements  and  procedures.  The  system  shall 
provide  reliable  guides  to  cue  the  user  for  normal  and  emergency/critical 
response  as  well  as  keeping  him  informed  about  where  he  is  in  the  current 
process  and  what  the  system  status  is. 

B.  FUNCTIONS  OF  A  TACTICAL  MAN-MACHINE  INTERFACE 

The  typical  MMI  of  current  CDS’s  is  the  Standard  Navy  Display  Console 
(SNDC).  These  consoles  are  usually  daisy-chained  in  groups  to  a  central  computer 
and  provide  a  variety  of  functions  for  interaction  with  the  software  system  and  control 
of  subsystems.  Functions  like  Range  Select,  Track  Filtering  and  Action  Entries,  to 
name  only  a  few,  are  implemented  in  discrete  hardware  provided  by  the  consoles, 
making  these  devices  complex,  expensive  and  specialized  for  their  particular  purpose. 
To  provide  an  operator  with  the  basic  skills  for  using  a  SNDC  requires  training 
periods  measured  in  terms  of  months.  For  further  information  on  SNDC  see  the 
Combat  Direction  Systems  Specification  for  Surface  Ships  [Ref.  7]. 

During  the  requirements  analysis  for  the  LCCDS  it  became  obvious  that  the 
development  of  a  MMI  would  be  one  of  the  main  issues  for  this  project.  The 
implementation  of  the  LCCDS  as  a  subset  of  existing  CDS’s  makes  it  necessary  to 
implement  CDS  functionality  as  provided  by  SNDC  on  bitmapped  workstation 
displays  that  do  not  provide  the  hardware  features  of  a  SNDC. 

The  prime  objective  of  the  Man-Machine  Interface  is  to  insulate  the  user  from  the 
non-essential  detail  and  highlight  the  information  he  needs  to  have.  This  must  be 
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done  in  a  manner  which  provides  intuitive  tools  for  accurately  representing  the  tactical 
problem  comprehensibly  to  the  user.  Humans  normally  do  not  perform  well  in 
situations  requiring  concurrent  thought  processes.  If  the  user  must  concentrate  on 
operating  the  tool,  he  cannot  also  be  concentrating  on  the  information  it  provides  him. 
The  representation  of  tactical  information  using  current  workstation  technology 
(supporting  color,  aural  cues  and  speech  recognition)  can  allow  operators  to  make 
better,  faster  and  more  accurate  tactical  decisions,  with  significantly  less  training  and 
experience. 

Irregardless  of  mission  or  tactical  circumstance,  a  ship’s  external  sensors 
provide  only  one  thing,  raw  data.  This  data  becomes  useful  only  after  human  analysis 
assigns  meaning  to  it.  The  key  to  this  crucial  step  lies  in  the  capabilities  and  design 
of  the  MMI.  The  technology  exists  which  will  allow  the  MMI  to  be  the  "expert"  at 
translating  the  real  world  environment  into  a  manageable  subset  of  tactically 
significant  information,  easily  recognizable  by  the  user. 

A  pre -defined,  well- understood  "Display  Doctrine"  (see  Goal  1.3)  provides  the 
primitive  guidelines  by  which  the  MMI  filters,  molds  and  represents  tactical 
information  in  some  form  which  attaches  the  desired  priority  and  significance  to  the 
data  it  passes  to  the  user.  An  important  part  of  this  MMI  is  its  ability  to  extend  over 
new  and  changing  situations  and  requirements.  It  must  be  easy  to  modify  and  add 
new  "filters"  to  the  display  doctrine.  A  ship  may  have  many  different  missions  or 
operations,  therefore  the  MMI  mu't  be  capable  of  providing  data  from  many  different 
tactical  perspectives. 

To  give  a  simplified  view  on  the  process  of  collecting  filtering  and  displaying 
tactical  significant  information  consider  Figure  70.  A  sensor,  typically  a  radar,  sonar 
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or  optical  device  detects  environmental  phenomena  and  converts  it  into  quantifiable 
data.  Problems  with  these  first  filters  are  that  not  all  phenomena  are  recognized  and 
not  all  recognized  phenomena  will  finally  turn  out  to  be  tactically  significant.  In  the 
next  step,  the  data  is  collected  and  stored  in  some  way  in  a  database  system.  Now 
the  next  filter  can  be  applied  on  the  stored  data  in  order  to  get  knowledge  about  the 
origin  and  nature  of  the  phenomena  associated  with  the  data.  Algorithms  determine 
positions,  course,  speed  and  other  characteristics  of  the  phenomena,  changing  data 
into  meaningful  information.  The  information  is  further  refined,  via  Display  Doctrine, 
as  it  passes  to  the  MMI.  Information  must  be  organized  into  a  human 
understandable  form.  An  optimization  takes  place,  that  allows  the  user  to  recognize 
the  phenomena  in  the  fastest  possible  way.  The  goal  is  to  provide  the  user  with  only 
that  information  that  is  tactically  significant  or  meaningful  without  any  losses.  At  this 
point  we  can  identify  one  of  the  critical  functions  of  a  tactical  MMI: 

(1)  An  effective  man-machine-interaction  requires  the  representation  of 
environmental  phenomena  as  meaningful  information  with  respect  to 
Human  Information  Processing. 

The  information  has  now  arrived  at  its  destination,  the  user.  Clearly 

i* 

Interpretation  and  Decision  are  based  on  the  cognitive  skills  and  experience  of  the 
user.  The  domain  of  the  MMI  is  the  support  of  Recognition  and  Reaction.  The  issue 
on  recognition  is  described  in  (1).  The  question  is  how  to  present  information, 
without  loss,  to  the  user  to  ensure  fastest  possible  recognition  without  reducing 
performance  and  attention. 

A  reaction  may  be  a  variety,  or  range,  of  responses  including  direct  intervention 
into  the  environment  (e.g.  releasing  a  weapon),  change  of  own  behavior  or  change  of 
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the  display  doctrine  in  order  to  amplify  the  information  content.  Within  this  range  the 
support  of  reaction  asks  for  the  most  appropriate  technique  for  interaction  to  ensure  a 
quick  and  error-free  response  to  the  information  stimulus  without  over- stressing  the 
user. 


K 


Fig*ire  70:  Simplified  Model  of  Information  Conversion 


So,  the  other  critical  function  for  the  MMI  can  be  stated  as: 


(2)  Provide  a  set  of  interaction  techniques  to  optimize  the  possibilities  for  the 
user  to  feedback  his  decision  into  the  system. 
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The  design  and  development  of  a  MMI  with  respect  to  recognition  support  will 
have  to  consider  the  concepts  of  visual  and  aural  perception: 

-  which  symbol  is  associated  to  what  information, 

-  which  sets  of  colors  to  use. 

-  how  best  to  integrate  aural  cueing  and  alerting  with  the  graphic  screen 
representation. 

Interaction  techniques  may  be  any  one  or  combination  of  the  following: 

-  commandline  interpreters. 

-  menu  systems. 

-  form  filling  systems. 

-  iconic  systems. 

-  window  systems. 

-  direct  manipulation  (activate  a  button  by  physical  touch  or  position  and 
selection  using  a  pointing  device). 

-  graphical  interaction  (drawing  tools). 

-  speech. 

C.  CO^OR  USE  AND  SCHEMES 

The  use  of  color  can  be  a  powerful  tool  in  the  exchange  and  management  of 
information  on  a  visual  display.  For  the  tactical  application  color  can  be  used  in  its 
qualitative  sense,  to  show  that  one  symbol,  or  class  of  symbols,  is  different  from 
another.  Color  can  impart  special  meaning  to  the  symbol.  This  meaning  can  be 
arbitrarily  assigned  by  the  user  or  designer,  or  it  can  be  selected  to  reinforce  existing 
stereotypical  information  and  assumptions.  In  any  case,  the  key  design  issues  for  the 
MMI  involve  how  much  color  to  use,  how  much  meaning  to  assign  and  how  much  user 
flexibility  in  color  selection  to  allow. 
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The  use  of  color  requires  care  and  restraint.  Too  much  color  blurs  any  meaning 
assigned  and  can  drastically  reduce  user  effectiveness.  Effective  color  usage  depends 
on  matching  physiological,  perceptual  and  cognitive  aspects  of  the  human  visual 
system  [Ref.  21  :p.  334],  Color  is  a  sensation.  It  is  perceived  a  little  differently  by 
everyone.  People  can  identify  a  particular  color  within  a  range,  yet  disagree  on 
shading  and  hue.  These  perceptions  may  change  with  age,  prolonged  viewing, 
brightness,  context  and  size  of  the  colored  area.  The  cognitive  issues  involved  with 
color,  i.e.  using  color  to  express  meaning,  are  greatly  affected  by  the  user  model. 
When  color  is  used  to  impart  information  based  on  user  concepts  already  established 
through  training  standards,  or  stereotypical  associations,  (such  as  red  for  hostile 
tracks,  danger,  stop  etc.)  it  can  be  quite  effective. 

Reference  21  provides  s^rne  general  guidelines  for  the  effective  use  of  color  on 
visual  displays: 

-  Do  not  overuse  color.  The  benefits  of  color  for  imparting,  organizing  or 
signalling  information  are  lost  if  too  many  colors  are  used.  In  consonance 
with  the  limits  of  human  working  memory,  limit  the  display  to  about  six 
clearly  discriminable  colors. 

I* 

-  A  void  the  simultaneous  display  of  spectrally  extreme  colors.  Viewing 
extreme  color  pairs  (such  as  red  and  blue  or  yellow  and  purple)  requires 
constant  refocusing  and  visual  fatigue. 

-  A  void  pure  blue  for  text,  thin  lines  and  small  shapes.  Blue  does  make  a 
good  background  color  and  is  perceived  clearly  out  into  the  periphery  of  our 
visual  field. 
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Avoid  adjacent  colors  which  differ  only  in  their  amount  of  blue.  Edges 
which  differ  only  in  amount  of  blue  appear  indistinct.  This  can  make  the 
display  appear  poorly  focused. 

Avoid  use  of  red  and  green  in  peripheral  areas  of  large  screen  displays. 
Retinal  peripheral  sensitivity  to  these  colors  is  poor.  Blue  and  yellow  are 
good  peripheral  colors. 

Not  all  colors  are  equally  readable  or  legible.  Extreme  care  should  be 
taken  in  choosing  foreground/background  colors  for  text.  Generally,  the 
darker  spectrally  extreme  colors  (red,  black,  brown,  blue)  make  better 
background  while  the  brighter,  spectrally  centered  colors  (white,  yellow) 
produce  more  legible  text. 

A  void  the  need  for  color  discrimination  in  small  areas.  The  human  visual 
system  produces  sharper  images  with  achromatic  colors.  For  fine  detail  or 
small  shapes  and  screen  areas  it  is  best  to  use  black,  white  and  gray. 
Reserve  use  of  the  chromatic  colors  for  larger  panels,  backgrounds  or  for 
attracting  attention. 

Group  related  functions  or  elements  by  using  a  common  background 
color.  A  successive  set  of  images  (such  as  a  series  of  overlapping  menu 
windows  related  to  a  function)  can  be  related  by  background  color. 

<  Brightness  and  saturation  draw  attention.  The  center  of  the  retina  (fovea) 
only  focuses  on  about  2  degrees  of  the  visual  field,  the  rest  is  peripheral. 
The  ability  to  differentiate  colors  degrades  as  the  object  recedes  into  the 
peripheral  visual  field.  The  brightest  and  most  h.ghly  saturated  (purest) 
area  of  color  will  immediately  draw  viewer  attention. 

"Warm"  and  "Cold"  colors  should  indicate  action  levels.  Traditionally, 
the  warm  colors  are  used  to  signify  action  or  need  for  a  response.  Cool 
colors  indicate  status  or  background  information.  Most  people  perceive 
warm  colors  as  advancing  toward  them,  thus  forcing  their  attention. 
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The  above  guidelines  offer  some  suggestions  to  keep  in  mind  when  designing  an 
MMI,  but  it  should  be  noted  that  they  cannot  be  considered  binding  for  all 
applications.  Once  again,  the  development  and  use  of  an  accurate  user  model  which 
draws  upon  training,  experience  and  stereotypical  information  pertinent  to  the  user 
and  environment  in  which  the  system  will  exist,  cannot  be  overemphasized. 

Each  person  perceives  color  slightly  differently  and  while  the  guidelines  for  color 
use  apply  well  in  the  general  case,  some  support  for  individual  idiosyncrasy  is 
necessary.  A  suggested  further  constraint  on  the  use  of  color  would  be  to  organize 
suitable  color  schemes  into  sets,  allowing  the  user  to  choose  from  the  available  sets 
but  not  individual  colors.  This  makes  the  users  choice  relatively  simple  and  quick, 
and  more  importantly  provides  the  system  designers  with  the  capability  to  enforce 
known  human  factors  standards  while  still  providing  a  range  of  preference  for  the 
user.  This  concept  is  used  in  the  MMI  for  NCCS-A  through  use  of  controlled  access 
(password)  to  a  Workstation  Configuration  Utility  w-hich  allows  the  user  to  change 
the  default  color  scheme  to  at  least  one  other  optional  scheme  [Ref.  5:p.  29]. 

D.  AURAL  CUES  AND  ALERTS 

i* 

Sound  and  the  human  capacity  for  hearing  provide  a  powerful  tool  for  human- 
computer  interaction  and  communication.  Aural  cueing  and  alerting  has  already 
proven  its  usefulness  in  the  tactical  environment  where  the  visual  channel  is  close  to 
overload. 

Human  hearing,  and  the  mental  processes  associated  with  it,  have 
evolved  to  where  verbal  communication  is  perhaps  the  greatest  means  for 
information  transfer.  Pattern  recognition  capabilities  of  human  hearing, 
however,  are  not  limited  to  speech  but  include  recognition  of  many  special 
characteristics  of  both  natural  and  man-made  sounds.  [Ref.  19:p.  422] 
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The  concept  of  sound  icons,  aptly  named  "earcons",  are  particularly  applicable  to 
the  LCCDS.  Many  of  the  sound  features  used  to  create  earcons  are  easily 
implemented  and  manipulated  on  current  workstations.  Patterns  of  sound  are  easily 
recognized  and  remembered,  even  in  the  presence  of  high  noise  levels.  The  parallel 
processing  involved  with  hearing,  like  that  used  in  vision,  provides  nearly 
instantaneous  recognition  of  sound  patterns.  [Ref.  19:p.  422] 

The  use  of  audio  for  implementation  of  system  cues,  alerts  and  warnings  can 
greatly  enhance  the  performance  and  reaction  time  of  the  user  in  an  environment 
where  parallel  activities  are  also  taking  place.  For  instance,  it  is  not  unusual  for  the 
user  in  the  Combat  Direction  Center  (CDC)  to  be  involved  in  intemal/extemal 
communications,  log-keeping  and  generating  reports.  The  human  eye  can  perceive 
the  visual  scene  over  a  wide  angle,  almost  to  180  degrees,  however,  visual  detail  is 
obtained  only  over  a  narrow  region  (about  two  degrees  across),  called  the  fovea  [Ref. 
20:p.  25 1 .  The  remainder  of  the  retina  provides  peripheral  vision  for  orientation.  This 
limitation  can  drastically  dilute  the  impact  of  visual  cues  in  an  environment  where  the 
user  is  not  always  focused  on  the  display.  Sound  icons  may  transmit  meaningful 
"chunks,r  of  information  much  faster  than  textual  messages  displayed  visually  or 
spoken  via  computer  synthesized  voice.  There  are  four  major  advantages  of  audio 
cueing  [Ref.  19:p.422[: 

1.  Users  need  not  pay  strict  attention  to  audio  cues,  relying  on  subconscious 
processes  to  detect  significant  events,  while  focusing  on  more  interesting 
tasks. 

2.  The  user  need  not  be  within  clear  line-of-sight  of  the  display.  Distance 
and  orientation  to  the  source  of  the  sound  is  completely  arbitrary. 
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3.  Well  designed  audio  cues  may  be  easier  to  learn  than  certain  other  forms  of 
communication  such  as  visual  icons. 

4.  The  visual  landscape  on  a  graphical  display  is  already  cluttered,  and  audio 
cues  would  limit  the  number  of  distracting  textual  messages. 

The  LCCDS  shall  provide  the  user  with  a  MMI  heavily  dependent  on  visual 
display  of  complex  data  and  spatial  relationships.  Use  of  audio  cues  to  augment  the 
intuitive  and  fast  exchange  of  information  and  control  between  man  and  machine  has  a 
number  of  constraints  as  well  as  advantages.  Deatherage  [Ref.  22]  provides  some 
basic  guidelines  as  follow: 

Use  auditory  presentation  if: 

1 .  The  message  is  simple. 

2.  The  message  is  short. 

3.  The  message  will  not  require  the  user  to  remember  it  for  later  reference. 

4.  The  message  deals  with  events  in  time. 

5.  The  message  calls  for  immediate  action. 

6.  The  visual  system  of  the  user  is  overburdoned. 

* 

E.  SPEECH  RECOGNITION 

Speech  recognition  systems  do  exactly  what  their  name  suggests;  they  recognize 
the  user’s  spoken  words.  The  words  are  typically  recognized  using  pattern  matching 
techniques  against  a  set  of  "acoustic  templates".  Once  the  word  is  recognized  it  is 
passed  to  some  higher  level  software  routine  for  syntactic  and  semantic  analysis. 

It  is  important  to  make  a  clear  distinction  between  speech  recognition  and  speech 
understanding.  A  speech  recognition  system  has  no  understanding  of  the  words  it 


"hears".  It  simply  matches  the  acoustic  pattern  of  the  sound  against  a  set  of 
predefined  templates.  Once  a  match  is  made,  higher  level  software  attaches  meaning 
as  specified  by  the  system  developers. 

There  are  four  generic  types  of  speech  recognition  systems  currently  available 
and  being  used  widely  by  industry.  These  can  be  split  into  two  groups;  (1)  speaker 
dependent  or  independent,  and  (2),  connected  or  discrete  speech  (either  may  be 
speaker  dependent  or  independent).  The  following  definitions  are  taken  from  Poock 
[Ref.  23]. 

1.  Speaker  Dependent 

A  speaker  dependent  system  will  reliably  respond  to  the  voice  inputs  of  only 
those  users  who  have  previously  "trained"  the  system.  In  this  context,  "training"  the 
system  refers  to  the  process  of  creating  a  set  of  acoustic  templates  for  each  user. 
Dependent  systems  come  equipped  with  special  software  which  allows  the  user  to 
define  his  own  vocabulary,  then  provide  speech  samples  to  the  system.  These 
samples  are  used  to  form  the  templates.  In  other  words,  a  dependent  system  needs 
to  hear  not  only  the  right  words,  but  the  right  voice  as  well.  When  the  system 
(generally,  for  most  systems)  has  what  it  considers  to  be  a  good  sample,  it  will  notify 
the  user  that  it  has  been  adequately  trained.  At  this  point  the  system  is  ready  for 
actual  use.  These  systems  require  that  each  user  "log  in"  when  ready  to  use  the 
speech  recognition  system  so  the  proper  set  of  acoustic  templates  can  be  loaded  into 
memory. 

Proper  training  of  the  speaker  dependent  system  is  of  the  utmost  importance 
in  assuring  reliable  recognition  of  the  vocabulary  for  any  particular  user.  Poock  [Ref. 
23]  at  the  Naval  Postgraduate  School  is  conducting  research  in  the  areas  of  speech 
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applications  and  how  to  most  effectively  train  speaker  dependent  systems  for 
optimum  reliability  and  performance. 

2.  Speaker  Independent 

A  speaker  independent  system  contains  more  complicated  algorithms  which 
enable  it  to  recognize  many  different  voices  and  dialects.  These  systems  require  no 
previous  "training"  by  prospective  users.  They  should  be  able  to  recognize  anyone 
who  tries  to  use  the  system. 

Theoretically,  the  speaker  independent  systems  are  not  as  reliable  as 
dependent  systems,  but  both  systems  are  showing  recognition  accuracies  in  the  97- 
99%  range  for  vocabularies  of  several  hundred  words  (for  the  normal  office 
environment).  [Ref.  23] 

The  next  two  areas  of  speech  recognition  are  concerned  with  the  way  in  which 
the  user  speaks  to  the  system.  Both  Discreet  and  Connected  may  be  used  with 
either  speaker  dependent  or  independent  systems. 

3.  Discrete  Speech 

A  discrete  system  contains  a  given  number  of  sound  patterns  which  the  user 

I* 

may  speak.  A  sound  pattern  may  be  a  single  word,  or  phrase  which  is  associated 
with  a  single  acoustic  template.  When  using  the  discrete  system,  the  speaker  must 
pause  between  each  word  or  phrase  (utterance)  he  makes.  Depending  on  the 
system,  this  required  pause  is  normally  in  the  range  of  100-250  milliseconds.  When 
the  system  "hears"  the  pause,  the  utterance  is  ended  and  the  system  searches  the 
available  templates  for  a  match  in  order  to  determine  what  was  just  said. 
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4.  Connected  Speech 


Connected  speech  requires  no  pause  between  utterances.  These  systems 
contain  an  algorithm  which  determines  word  boundaries.  Connected  speech, 
especially  for  digit-type  strings  of  input,  is  much  more  natural  for  the  human  user  than 
discrete  speech  input  [Ref.  23].  Some  existing  connected  speech  systems  are 
especially  impressive  in  that  they  continuously  monitor  what  the  user  says 
recognizing  valid  connected  speech  portions  and  ignoring  the  rest. 

5.  Applications  for  Speech  Recognition 

There  are  very  few  things  a  human  can  do  concurrently.  Physical  and  cognitive 
limitations  preclude  doing  things  in  parallel.  Under  certain  circumstances  however, 
speech  can  be  an  exception.  Speech,  in  conjunction  with  other  visual  or  graphic 
oriented  activities  is  a  common  occurrence.  A  common  instance  is  holding  a 
conversation  while  driving  your  car.  Another  could  be  positioning  the  Ball  Tab  over  a 
track  symbol  on  the  TacPlot  while  invoking  menu  selections  made  and  executed  via 
speech  input.  Speech  input  is  useful  when:  [Ref.  23] 

1.  Eyes  are  busy. 

2.  Hands  are  busy. 

3.  Darkness  or  low  light  levels  exist. 

4.  You  wish  to  enter  data  but  your  hands  are  not  in  a  position  to  touch  a 
keyboard.  You  could  use  either  a  hardwired  or  wireless  mike  for  data 
entry,  even  though  the  distance  between  user  and  keyboard  is  small. 

6.  Conclusions  on  Speech  Recognition 

It  becomes  obvious,  once  the  capabilities  of  speech  recognition  are  known, 
that  there  are  many  applications  for  the  tactical  environment.  More  research  in  the 
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further  development  and  tactical  application  of  speech  I/O  is  necessary.  Poock  [Ref. 
23]  points  out  that  the  biggest  stumbling  block  with  technical  applications  of  speech 
I/O  is  that  people  are  just  not  aware  of  what  it  can  really  do  for  them. 

F.  AN  EXTENSIBLE  MMI 

Any  interface  that  permits  additional  functionality  or  capability  to  be  included  in 
an  existing  system,  as  the  system  is  used  and  new  applications  and  ideas  develop, 
can  be  considered  extensible.  This  concept  covers  a  broad  range  of  capabilities 
whose  primary  purpose  is  to  handle  varying  levels  of  user  experience  and  build  in 
some  support  for  future  growth.  These  capabilities  cover  a  broad  range,  from 
keyboard  macros,  or  "hot  keys"  in  lieu  of  menu  selections,  to  the  ability  for  the  user  to 
define  new  functions.  The  ability  to  incorporate  new  methods  and  ideas  into  existing 
form  and  function,  quickly  and  easily  by  the  user  himself,  can  have  a  major  impact  on 
the  efficiency  and  reliability  of  tactical  decision  tools  such  as  the  LCCDS.  Two 
suggested  starting  places  for  extensibility  are  in  the  "display  doctrine"  and  the 
Tactical  Database. 

The- display  doctrine  (defined  in  detail  in  Chapter  II)  is  that  set  of  rules  and 
tactical  parameters  the  system  applies  to  the  processed  data  to  transform  or  filter  it 
into  usable,  comprehensible  information.  Much  of  the  display  doctrine  will  take  the 
form  of  existing  NTDS  data  display  standards.  However,  it  should  also  provide  the 
user  with  the  capability  to  create  his  own  functions  for  data  manipulation,  more 
focused  on  his  specific  requirements.  The  ability  to  do  this  could  provide  endless 
applications  for  specific  mission  requirements,  tactical  doctrine,  navigation  safety,  etc. 

The  Tactical  Database  shall  hold  all  the  data  related  to  NTDS  standard 
symbology,  associated  data,  and  Special  Points  created  with  the  workstation 
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enhanced  graphics  capability.  In  support  of  MMI  extensibility,  this  database  should 
allow  the  user  to  identify  newly  created  graphic  objects,  symbols  and  associated  data 
as  valid  objects  to  be  recognized  and  stored  (if  desired)  as  part  of  the  Tactical 
Database.  Additionally,  once  a  user  created  object  has  been  incorporated  into  the 
Tactical  Database,  the  user  should  have  the  capability  of  assigning  or  defining  the 
operations  allowed  on  it  via  the  Display  Doctrine. 

An  additional,  more  complex  form  of  extensibility  is  the  concept  of  adaptive 
interfaces.  Simply  put,  it  means  the  MMI  should  adapt  to  the  user  rather  than  the 
user  adapt  to  the  system.  There  are  two  forms  of  adaptive  interface.  One  way  is  to 
allow  the  user  to  make  his  own  modifications  to  the  MMI  if  he  finds  the  behavior  of 
the  system  unsatisfactory  once  he  has  used  it.  The  idea  is  that  the  MMI  may  be 
changed  by  several  classes  of  user.  These  classes  cover  the  range  from  novice  to 
expert.  The  amount  of  MMI  change  allowed  is  dependent  on  the  user  who  wants  to 
make  the  change  and  the  access  privileges  he  has  to  the  internals  of  the  interface. 
This  can  produce  a  better  interface,  but  it  does  leave  the  burden  of  adapting  to  the 
user  [Ref.  24:p.  2]. 

The"  second,  much  more  complex,  form  is  dynamic  adaptation  by  the  system 
itself.  In  this  case  the  interface  changes  with  respect  to  particular  user  and  current 
context.  The  MMI  learns  with  respect  to  each  individual  user.  This  implies  the 
interface  may  work  differently  for  each  user  within  the  same  task  context.  For 
optimal  system  performance,  the  dynamically  adaptive  MMI  should  be  able  to 
compensate  for  the  inherent  biases  of  the  user  [Ref.  24:p.  3]. 

Along  with  the  obvious  power  and  friendliness,  there  are  a  number  of  negative 
aspects  associated  with  dynamic  interfaces.  They  are  complex  and  require  a  lot  of 
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system  resources,  but  more  importantly,  the  user  may  not  be  able  to  develop  a 
coherent  model  of  the  system  if  it  changes  frequently.  This  may  undermine  the  users 
confidence  and  performance  with  the  system.  If  the  user  does  not  have  a  clear 
understanding  of  the  system  behavior  his  effectiveness  can  be  seriously  reduced. 
[Ref.  25] 

We  have  attempted  to  incorporate  the  first  method  of  adaptation,  letting  the  user 
make  his  own  modifications,  in  the  LCCDS.  The  desired  level  of  user  friendliness 
flexibility  can  be  supported  while  at  the  same  time  minimizing  any  risk  of  violating  the 
users  conceptual  model  of  the  system.  The  model  only  changes  when  the  user 
decides  to  change  it.  This  concept  of  adaptability  falls  within  the  NAVSEA  guidance 
[Ref.  4]  for  the  LCCDS  and  the  SPAWAR  NCCS-A  Workstation  Executive 
specification  [Ref.  5]. 
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V.  CONCLUSIONS 


A.  RECOMMENDATIONS 

1.  Forma!  Approach 

This  thesis  is  intended  to  provide  the  first  stage  or  activity  within  the 
software  development  cycle  as  outlined  by  Berzins  [Ref.  6].  Chapter  II  provides  the 
goals  and  constraints  of  the  LCCDSWS  representing  the  initial  requirements. 

However,  not  all  goals  could  be  refined  as  necessary.  In  particular  goals  4.4 
and  4.5  could  not  be  refined  sufficiently  since  the  interface  descriptions  are  not  yet 
available  and  will  have  to  be  added  at  a  later  time. 

In  the  same  way  we  do  not  expect  the  goal  hierarchy  to  be  complete.  Further 
refinement  of  goals,  addition  of  new  subgoals  or  reorganization  of  the  hierarchy  might 
be  necessary  as  knowledge  on  details  is  gained  in  further  stages  of  the  development 
cycle. 

The  goal  hierarchy  is  not  yet  completely  defined,  but  the  requirements 
analysis  can  be  continued  now  by  providing  functional  specifications  for  the  proposed 
system.  The  goal  of  this  stage  is  to  precisely  define  the  external  interfaces  of  the 
system.  The  combination  of  initial  requirements  and  functional  specification  is 
referred  to  as  the  final  requirements  [Ref.  6:  p.  3-1],  Chapter  III  provides  a  high  level 
definition  of  system  processes  and  data  objects  necessary  to  support  communication 
between  LCCDSWS  and  the  external  interfaces.  The  next  activity  in  the  software 
development  cycle  is  the  architectural  design  which  decomposes  the  system  into 
software  modules.  And  finally,  the  goal  of  the  implementation  is  to  construct  a 
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program  that  correctly  realizes  the  specified  interfaces  for  each  module  identified 
during  architectural  design  and  meets  the  associated  performance  constraints  [Ref.  6: 
p.  1-9). 

The  concept  of,  and  relations  between,  the  different  stages  of  the  software 
development  cycle  are  shown  in  Figure  2  (page  8).  Down-arrows  show  the  normal 
flow  of  execution,  up-arrows  represent  details  gained  at  later  stages,  which  require 
the  repetition  of  an  earlier  step.  The  large  loop  labeled  "Evolution"  demonstrates  that 
the  software  system  is  subject  to  changes  due  to  altered  operating  conditions  or  user 
needs,  resulting  in  a  new  version  of  the  system.  The  main  difference  between  the 
initial  development  and  later  evolution  is  that  many  parts  of  the  exisnng  version  can 
be  re-used  in  the  next  version  [Ref.  6:p.  1-4].  We  propose  that  these  steps,  applied 
to  the  LCCDSWS  development,  represent  the  baseline  to  be  carried  out  via  further 
thesis  work  at  NPS. 

2.  Rapid  Prototyping 

During  the  development  of  software  systems,  especially  hard  real  time 
systems,  a  worthwhile  effort  to  increase  software  development  productivity  is  rapid 

l* 

software  prototyping.  The  idea  behind  rapid  prototyping  is  to  create  a  prototype  of  the 
proposed  system  to  verify  that  the  real  time  behavior  demanded  by  a  customer  is 
feasible  under  the  imposed  constraints.  This  can  save  tremendous  amounts  of 
resources  in  terms  of  time,  effort  and  money.  The  feasibility  of  a  system  is  verified 
before  commitment  to  an  actual  implementation  is  made.  Design  errors  can  be 
detected  more  easily  and  are  cheaper  to  correct  at  this  point  ( especially  compared  to 
redesigning  and  recoding  a  finished  product  which  does  not  meet  the  requirements). 
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One  such  system  for  rapid  prototyping  is  CAPS  (Computer  Aided  Prototyping 
System),  which  is  based  on  PSDL  (Prototype  System  Description  Language).  CAPS 
is  presently  under  development  in  a  research  project  at  NPS  [Ref.  26,  27,  28]  and  can 
be  characterized  as  a  composition  of  separate  tools  which  provide  the  means  to 
create  a  prototype  of  a  software  system.  CAPS  will  provide  an  integrated 
environment  for  the  development  and  testing  of  prototypes  of  software  systems.  It  is 
especially  of  interest  for  LCCDS  because  the  system  will  automatically  translate  the 
PSDL  descriptions  of  a  system  into  Ada  code  and  compile  them  so  that  they  could  be 
executed  to  demonstrate  the  prototype.  CAPS  is  specifically  designed  to  address 
large  embedded  systems  which  have  hard  real-time  constraints  and  employs  a 
database  system  to  store  and  recall  reusable  software  components  in  the  Ada 
language. 

The  requirements  definition  process  is  the  most  difficult  and  error  prone  phase 
of  software  system  development.  The  use  of  informal  requirements  definitions,  rapid 
prototyping  systems  and  formal  design  languages,  such  as  PSDL,  together  work  to 
bridge  the  conceptual  gap  between  the  users  desires,  designers  concepts  and  final 
implementation.  The  importance  of  the  prototype  is  that  it  provides  the  capability  for 
generating  "quick-and-dirty"  samples  of  eventual  system  functions  and  capability 
which  the  user/customer  can  see  and  feel.  A  rapid  prototyping  system  can  provide 
the  vehicle,  early  in  the  requirements  definition  phase,  for  uncovering  design  errors, 
inconsistencies  and  misconceptions  which  might  otherwise  grow  into  costly  design  or 
maintenance  changes  later  in  the  software  life-cycle. 

We  recommend  to  use  CAPS  to  study  the  real-time  behavior  and  feasibility  of 
the  LCCDSWS  as  soon  as  CAPS  becomes  operational. 
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3.  Further  Research 


One  of  the  characteristics  of  Berzins’  formal  software  engineering  approach  is 
the  concurrent  nature  (hence  the  bi-directional  arrows  in  Figure  2)  of  these 
activities.  This  provides  an  opportunity  to  work  on  different  aspects  of  the  project 
simultaneously.  One  of  these  aspects  is  the  use  of  commercially  available  software 
packages  as  suggested  by  NGCR  [Ref.  3].  These  packages  are  tested  and  debugged 
through  "best  commercial  practice".  With  developments  amortized  by  thousands  of 
commercial  users  considerable  reduction  in  both  development  time  and  cost  can  be 
achieved.  In  the  following  paragraphs  we  provide  some  examples  for  such  packages 
as  they  may  apply  to  the  LCCDS  development. 

a.  Commercial  Databases 

Increment  One  of  the  LCCDS  requires  the  selection  of  a  suitable  object- 

oriented  database  management  system  for  the  project.  Ross  [Ref.  16]  evaluates 

three  possible  systems  and  shows  that  GemStone,  a  product  of  Servio  Logic 

Corporation,  Alameda,  Ca.,  best  Fits  the  requirements  of  this  project.  To  determine 
(• 

the  usefulness  of  this  package  it  is  necessary  to  install  this  database  on  a  UNIX  OS 
and  implement  an  interface  to  the  Ada  language  as  suitable  for  the  LCCDSWS. 

b.  Real-Time  Operating  System 

One  of  the  drawbacks  in  using  the  UNIX  operating  system  for  the 
LCCDSWS  development  is  that  it  does  not  provide  real-time  mechanisms.  To  make 
the  step  from  the  prototype  to  an  operational  system  it  is  necessary  to  select  one  of 
the  commercial  available  UNIX-derived  operating  systems,  which  provide  these 
mechanisms  and  install  it  on  the  proposed  Sun  Microsystems  Sparcstation  1.  It  is 
expected  that  software  for  the  project  developed  on  UNIX  will  retain  compatibility. 
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e.  MMI 


The  Man-Machine-Interface  will  be  one  of  the  most  complex  modules 
within  LCCDSWS.  Implementation  of  this  interface  using  commercial  available 
software  tools  should  be  considered.  The  X  Window  System  is  a  network-oriented, 
server-based  windowing  system  developed  at  MIT.  It  is  supported  by  most  vendors 
of  UNIX-based  workstations  and  is  becoming  a  standard  in  this  environment. 
Applications  will  usually  use  the  Xlib  toolkit  and  widgets,  software  tools  that  include 
a  text  editor,  menus,  scroll  bars,  icons  and  command  buttons.  X  Windows  is 
available  at  NPS,  some  research  has  already  been  carried  out  with  respect  to  the 
LCCDSWS.  X  Windows  can  be  used  to  implement  the  MMI  for  LCCDSWS  once  an 
interface  to  the  Ada  language  has  been  written. 

An  important  option  to  explore  is  the  use  of  existing  software  for  the 
NCCS-A  Workstation  MMI  currently  under  development  at  NOSC.  The  OPNAV 
sponsor  for  NCCS-A,  OP-942F4,  has  offered  NPS  full  use  of  all  NCCS-A  MMI 
object  code  for  incorporation  into  LCCDS  [Ref.  29]. 
d.  Reusable  Software 

P 

Another  finding  of  the  research  for  LCCDS  is  the  existence  of  general 
purpose  Ada  software  packages  on  the  SIMTEL20  software  repository.  This 
repository  contains  a  variety  of  generic  data  structures  and  algorithms,  software 
engineering  tools  and  highly  specialized  applications.  An  example  for  reusable 
software  is  the  Kalman-Tracking-Filter  package  contained  in  SIMTEL20  which 
provides  real-time  tracking  algorithms.  The  SIMTEL20  software  is  available  at  NPS 
(and  for  anyone  else  on  DDN)  and  should  be  explored  in  depth  to  identify  packages 
that  can  be  used  for  the  LCCDSWS  development  in  particular  and  the  software 
development  life-cycle  in  general. 
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e.  Rewrite  existing  Software  in  Ada 

The  NGCR  report  recommends  serious  consideration  of  rewriting  existing 
software  into  Ada  [Ref.  3  :p.  2).  This  in  particular  is  a  promising  approach  for 
LCCDSWS  since  all  of  the  CDS  functions  as  required  in  goal  4  are  implemented  in  the 
CMS-2  language  for  currently  operational  CDS’s.  These  systems  should  be 
analyzed  to  determine  which  algorithms  would  be  both  useful  for  the  LCCDSWS  and 
feasible  for  an  Ada  rewrite. 

B.  EVOLUTION  OF  THE  LCCDS 

Evolution  is  the  process  of  modifying  or  extending  the  functionality  of  a  softw'are 
system.  It  may  be  a  response  to  changes  in  user  requirements  or  part  of  a  planned 
phased  development  of  a  system  as  a  series  of  increasingly  sophisticated  versions 
[Ref.  6:p.  1-10).  The  initial  requirements  stated  in  Chapter  II  represent  a  detailed 
refinement  of  the  "user"  high-level  requirements  outlined  in  the  NAVSEA  Statement 
of  Work  [Appendix  A[.  In  this  chapter  we  envision  the  evolution  of  LCCDS  in  terms 
of  two  sets  of  possible  enhancements  to  the  system.  Section  A  describes 
modifications  to  the  basic  version  of  the  LCCDSWS.  Section  B  concerns  functional 
extensions  of  LCCDSWS. 

1.  Modifications  to  the  Basic  LCCDSWS 

The  functionality  described  in  the  Chapter  II  requirements  form  a  small  subset 
of  current  CDS  capability.  The  primary  purpose  of  these  requirements  is  to  define  a 
small  scale,  prototype  LCCDSWS.  Once  the  system  has  been  developed  to  the  point 
where  some  performance  and  functional  evaluation  can  be  done,  perhaps  after 
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Increment  One  is  complete,  it  may  be  appropriate  to  consider  some  greater  functional 
capabilities.  We  propose  several  enhancements  to  the  LCCDS  in  the  following 
paragraphs. 

a.  Trial  Maneuver 

This  function  was  brought  to  our  attention  by  Surface  warfare  officers  who 
have  used  the  Raytheon  Collision  Avoidance  System  (RAYCAS)  installed  on  the 
bridge  of  some  Naval  combatants.  The  system  we  looked  at  was  installed  on  the 
USS  Ranger  in  San  Diego,  CA.  RAYCAS  provides  an  easy-to-use  digital  MMI 
directly  superimposed  over  a  Radar  repeater.  NTDS-like  symbology  can  be  imposed 
over  digitized  Radar  video.  RAYCAS  operates  in  one  of  two  modes;  True  or 
Relative.  True  mode  displays  all  contacts  with  speed  leaders  oriented  to  true  course 
and  speed  through  the  water.  Relative  mode  displays  all  contacts  with  speed  leaders 
relative  (to  ownship  course/speed)  course  and  speed.  In  addition  to  providing  the 
usual  information  regarding  course,  speed  and  CPA,  the  RAYCAS  also  provides  a 
function  called  "Trial  Maneuver”.  This  function  greatly  enhances  the  user’s  ability  to 
visualize  the  relative  motion  between  moving  objects  and  Ownship.  Further,  it 
allows  for  insertion  of  trial  course  and  speed  alterations  showing  the  user  their 
overall  effect  on  all  other  displayed  surface  contacts  before  they  actually  maneuver 
the  ship.  This  has  proved  to  be  immensely  useful,  especially  when  navigating 
congested  waters. 

b.  Optimum  Route  Planning 

Optimum  route  planning  refers  to  the  capability  of  specifying  some 
(possibly  large)  number  of  conditions  which  affect  the  route  by  which  a  vessel  may 
proceed  from  one  point  to  another.  In  a  tactical  environment  the  constraints  on 
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movement  from  place  to  place  become  extremely  complex.  A  large  number  of  factors 
must  be  taken  into  account  for  transit  of  naval  vessels.  For  example,  necessity  for 
avoiding  detection,  position  and  plans  of  other  battle  group  units,  rapidly  changing 
intelligence  information,  satellite  and  aircraft  reconnaissance  coverage,  etc.  all  must 
be  considered. 

Equally  complicated  is  route  planning  for  CLF  vessels  conducting  "delivery 
boy"  operations  for  fleet  support  underway.  A  CLF  ship  is  normally  tasked  to 
rendezvous  with  several  ships  in  a  battle  group  for  purposes  of  underway 
replenishment  (UNREP).  The  task  of  planning  an  efficient  UNREP  schedule  is 
difficult  and  complicated,  involving  analysis  of  current  and  projected  positions  of 
several  ships,  distances  between  and  time  alongside  each  ship. 

This  situation  is  similar  to  the  "travelling  salesman"  graph  problem  with 
the  exception  that  all  the  "cities"  are  moving.  The  application  of  graph  analysis  and 
artificial  intelligence  (expert  or  "rule  based"  systems)  to  help  determine  optimum 
routes  for  complex  situations  could  be  extremely  beneficial  for  efficient  tactical  and 
logistic  planning. 

c.  Speech  Input 

The  use  of  speech  recognition  software  could  be  used  to  solve  some  of  the 
harder  problems  associated  with  the  LCCDS  MM1  and  other  interfaces.  There  are 
difficulties  associated  with  supporting  a  wide  range  of  user  expertise,  interfacing 
LCCDS  with  existing  shipboard  systems  (primarily  radar),  and  even  deciding 
between  use  of  a  trackball  over  a  mouse. 

Speech  recognition  as  an  input  medium  may  apply  to  a  large  number  of 
LCCDS  functional  areas.  Several  are  discussed  in  the  following  paragraphs. 
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d.  System  Control 

LCCDS  uses  menu-driven  system  control.  The  user  will  spend  most  of  his 
time  in  dialog  with  the  system  via  mouse/trackball/cursor  controlled  menu  selection 
processes.  It  would  be  much  faster  to  use  speech  recognition  and  let  the  user  simply 
tell  the  system  what  he  wants.  The  menus,  also  activated  via  speech  input,  would 
still  be  available  to  aid  the  user  by  providing  available  options. 

e.  Trackball  Functions 

The  use  of  a  mouse  or  trackball  driven  cursor  to  identify  objects  (tracks, 
menu  choices,  windows,  etc.)  for  program  action  requires  a  button,  or  set  of  buttons, 
which  you  "click"  or  "drag"  as  necessary.  This  works  okay  for  a  mouse,  but  is  hard 
when  using  a  trackball.  To  use  a  trackball  the  user  really  must  have  both  hands  free, 
but  this  can  become  very  clumsy  and  inconvenient  when  he  has  something  better  to 
do  with  one  of  his  hands  (such  as  manipulate  keys  on  his  keyboard).  The  mouse 
doesn’t  present  this  problem,  but  does  have  other,  possibly  more  serious  problems. 
You  must  have  a  fairly  large  space  to  run  it  around,  and  from  a  maintenance 
perspective,  it  may  not  be  suitable  for  the  harsh  shipboard  environment. 

Speech  recognition  could  be  used,  in  lieu  of  physical  buttons,  with  the 
trackball  to  provide  the  click/drag  function  while  the  user  positions  the  trackball.  The 
cursor  is  positioned  using  one  hand,  objects  pointed  to  are  identified  verbally,  and  the 
user’s  other  hand  is  free. 

/.  Radar  Interface 

The  Radar  interface  must  extract  the  required  positional  information  from 
the  raw  video  provided  by  the  Radar  system,  digitize  or  format  it,  and  send  it  to  the 
LCCDS.  Hardware  implementation  of  this  will  be  costly  and  time  consuming.  It  is 
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possibly  to  provide  raw  radar  information  directly  to  the  LCCDS  using  speech 
recognition. 

It  is  Navy  SOP  to  have  an  operator  always  available  to  analyze  and  report 
the  radar  picture.  This  operator  is  on  a  sound-powered  phone  circuit  with  bridge  and 
CDC  personnel,  providing  radar  contact  information  in  a  standard  format  for  all  to  use. 

With  the  addition  of  a  microphone,  appropriate  for  use  in  a  speech  system, 
hardwired  to  the  LCCDS,  this  radar  information  could  be  input  directly  into  the  tactical 
database  just  as  if  the  information  had  come  across  an  actual  hardware  radar 
in*“rface.  The  radar  operator  passes  information  as  he  normally  would,  only  now  it 
goes  directly  into  the  system  as  well  as  up  on  the  various  status  boards. 

2.  Extensions  of  the  LCCDS  Functionality 
a.  Training  Function 

People  who  interact  with  a  software  system  need  training  on  proper  use  of 
that  system.  Users  need  to  develop,  maintain  and  expand  on  their  conceptual  model 
of  the  system.  They  need  to  enter  data,  fill  in  forms,  make  queries,  interpret  system 
responses  and  so  on.  Training  is  necessary  to  increase  the  Operational  Readiness  of 
a  CDC  team.  Training  for  a  ship-based  combat  direction  system  can  be  carried  out 
while  a  ship  is  at  sea,  with  all  subsystems  like  navigation,  radar.  Link  11  etc.,  fully 
operational.  The  "real  world  environment"  provides  the  scenario  an  operator  can  be 
trained  on.  However,  it  is  most  likely  that  operator  training  will  be  necessary  in  a 
situation  where  some  or  all  of  the  subsystems  are  not  available,  either  at  a  shore- 
based  training  facility  or  actually  onboard  the  ship  (i.ev  during  maintenance  periods, 
operational  standdowns,  etc.).  The  Training  Function  will  provide  the  capability  to 
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train  operators  in  such  a  situation  by  software  simulation  of  non-  operational 
subsystems  and  a  possibility  to  establish  an  artificial  scenario  for  training  purposes. 

Scenarios  can  be  divided  in  the  following  exercise  categories: 

-  Navigational  Practice:  the  operator  is  confronted  with  a  certain 
navigational  situation  where  he  has  to  ensure  safe  passage  using  the 
system. 

-  Anti-Collision  Exercises:  the  operator  has  to  use  the  system  to  carry 
out  anti-collision  procedures  to  avoid  collisions  with  simulated  surface 
tracks. 

-  Safe  ship-handling  and  formation  maneuvering  exercises. 

-  Link  1 1  Practice:  the  operator  has  to  carry  out  Link  11  track 
management. 

-  Combat  Exercises:  the  operator  is  confronted  with  simulated  air, 
surface  or  subsurface  attacks  or  a  combination  of  those,  including 
simulated  missile  and  gun  exercises. 

-  Combinations  of  the  above  for  more  sophisticated  scenarios. 

Scenarios  can  be  either  standard  predefined  "canned"  evolutions  for  each 
training  session  or  coordinated  exercises  involving  more  than  one  workstation  and 
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student.  Eventually,  these  LCCDS’s  should  have  all  the  necessary  training  software 
support  "built  in"  from  the  initial  design.  The  benefit  of  this  is  more  onboard  operator 
training  capability  and  less  dependence  on  scarce  shore-based  facilities. 
b.  CDS  F unctions 

(1)  Weapon  Interfaces.  One  of  the  most  important  features  of  a  combat 
direction  system  not  currently  supported  by  the  LCCDS  is  the  interface  to  a  weapon 
system.  The  need  for  such  an  interface  is  certainly  dependent  on  the  type  of  ship 
LCCDS  is  employed  on.  Non-combatant  CLF  ships,  possible  target  platforms  for  the 
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LCCDS,  are  not  equipped  with  weapon  systems.  However,  the  availability  of 
LCCDS  on  a  non-combatant  might  imply  the  need  for  such  a  system  as  the  next 
logical  step.  Possible  candidates  are  systems  for  Anti-Ship-Missile-Defense  such 
as  CIWS  or  RAM  (Rolling  Airframe  Missile).  For  small  combatants  (PHM’s  and 
amphibious  craft)  an  interface  to  the  Harpoon  Weapon  System  or  even  a  fire  control 
system  is  possible.  The  interfaces  should  provide  the  operator  with  the  capability  to 
employ  the  weapon  systems  in  their  various  operational  modes. 

(2)  Automatic  Multiple  CPA  Function.  The  CPA  function  of  the  basic 
LCCDS WS  calculates  the  CPA  of  a  track  on  user  request.  It  issues  a  warning  of  a 
Close  CPA  or  Collision  CPA  as  appropriate  when  the  track  is  within  certain  specified 
time  and  range  criteria.  The  Automatic  Multiple  CPA  Function  should  calculate  CPA 
values  for  all  surface  tracks  within  a  specified  range  and  issue  warnings  when  the 
criteria  are  met  automatically.  It  should  be  possible  to  enable  or  disable  this  function. 
c.  Simulation  Functions 

Simulation  Functions  should  provide  the  capability  to  simulate  external 
subsystems  of  the  LCCDS.  They  are  useful  in  two  ways:  first  they  allow  extensive 
system  testing  in  a  situation  where  the  use  of  external  subsystems  is  not  possible  or 
not  appropriate.  Second  they  support  the  training  functions  as  described  above.  The 
most  important  characteristic  of  simulation  functions  for  LCCDS  is  the  need  for  hard 
real-time  behavior  of  these  functions.  We  propose  the  following  set  of  simulation 
functions  for  LCCDS: 

-  Simulation  of  a  navigational  system; 

-  Simulation  of  a  radar  system; 
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-  Simulation  of  a  passive  Link  1 1  system; 

-  Simulation  of  weapon  systems  as  appropriate. 

3.  LCCDS  Future  Versions 

Based  on  the  above  modifications  and  extensions  we  can  now  provide  some 
considerations  on  possible  future  versions  of  LCCDS  employed  in  various  roles. 
a.  LCCDS  on  Non-Combatants 

The  user  requirement  for  LCCDS  as  stated  in  the  NAVSEA  Statement  of 
Work  [Appendix  A]  demanded  a  system  that  can  potentially  be  installed  on  non- 
combatant  ships.  A  possible  configuration  is  shown  in  Figure  71. 


Figure  71:  Non-Combatant  LCCDS 

It  can  be  expected  that  the  availability  of  a  low-cost  "mini"  combat 
direction  system  for  CLF  ships  may  imply  the  desire  for  an  air  self-defense  capability 
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for  these  units  by  installing  a  close-in  air  defense  weapon  system  (ClWS)such  as 
Phalanx.  Figure  72  depicts  such  a  configuration. 
b.  LCCDS  on  Small  Combatants 

Combat  Direction  systems  have  been  the  domain  of  large  combatant  units 
primarily  because  bulky  (and  very  costly)  equipment  made  an  installation  on  small 


Figure  72:  Non-Combatant  LCCDS  with  CIWS 


combatants  impossible.  For  PHM’s,  minesweepers  etc.,  LCCDS  can  be  a  feasible 
and  effective  upgrade.  LCCDS,  adapted  with  the  necessary  interfaces  to  weapon  or 
fire  control  systems  as  appropriate  may  look  something  like  Figure  73. 
c.  LCCDS  on  CDS  Equipped  Ships 

In  addition  to  the  installation  on  non-combatants,  the  NAVSEA  Statement 
of  Work  states  the  desire  for  installation  on  current  CDS  equipped  ships  to  augment 
the  existing  processing  capability.  We  propose  the  utilization  of  a  LCCDSWS  as  a 
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tactical  workstation  serving  in  a  particular  role.  For  example  workstations  could  be 
used  to  support  individual  elements  (e.g^ASMD,  EWC,  etc.)  of  the  warfare  task. 

The  tactical  workstations  can  form  a  separate  network  which  can  be 
interfaced  to  NTDS  via  gateways.  Tactical  workstations  employed  in  highly 
specialized  roles  are  expected  to  significantly  reduce  the  workload  of  the  central 


Figure  73:  Small-Combatant  LCCDS 


processor  (Figure  74).  The  graphics  capability  of  the  workstations  will  not  only 
improve  the  way  in  which  tactical  significant  information  is  represented,  it  also  opens 
a  whole  new  area  of  applications  for  tactical  information  management  and  access.  For 
example,  tactical  documentation  like  the  TAO  manual  could  be  made  available 
through  alphanumerical  windows.  Graphical  evaluation  and  processing  of  satellite 
photos  for  weather  or  intelligence  purposes  is  also  possible.  In-depth  human  factors 
research  on  the  methods  for  management,  organization  and  display  of  complex  tactical 
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information  in  the  workstation  environment  is  being  conducted  by  Osga  [Ref.  30]  at 
the  Naval  Ocean  Systems  Center  (NOSC)  in  San  Diego. 

d.  A  CDS  Based  on  Distributed  Architecture  and  Tactical  Workstations 

One  of  the  dangerous  bottlenecks  of  existing  CDS  is  the  centrally  located 
CPU  of  these  systems.  The  breakdown  of  this  unit  reduces  the  capabilities  of  the 
CDS  significantly  and  can  resqlt  in  a  total  loss  of  the  current  tactical  picture.  The 


Figure  74:  LCCDS  as  CDS  Tactical  Workstation 


replacement  of  the  CPU  by  networked  workstations  (Figure  75)  provides  a  variety  of 
benefits.  The  first  is  improved  system  survivability. 


A  failing  workstation  can  not  affect  the  functionality  of  the  network  or  any 
other  workstation.  It’s  tasks  can  easily  be  taken  over  by  another  station  or  a  spare 
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station  until  the  failing  unit  is  replaced.  Thus  the  breakdown  of  one  or  several 
components  reduces  the  vulnerability  of  the  system  to  hardware  failures  in  a  lesser 
degree. 


Figure  75:  Future  CDS  -  Distributed  Architecture  Using  Tactical  Workstations 


Other  aspects  are  cost  and  performance.  LCCDS  can  here  provide  what 
its  name  implies:  a  low  cost  system  but  with  increased  system  performance!  A 
rugged  SOLARIS  SPARCstation  300E  provides  16  MIPS  and  up  to  56  MBytes  of 
main  memory  at  $90,000  compared  to  3.5  MIPS,  up  to  5.2  MBytes  and  $2,000,000  of 
a  AN/UYK-43  [Ref.  31J. 
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The  implication  is  that  use  of  a  distributed,  "open  system"  type  of  CDS 
architecture  can  be  beneficial  is  a  wide  range  of  areas.  These  include  both  purely 
tactical  issues  such  as  enhanced  user  interfaces,  survivability,  modularity  of 
resources,  reliability,  ease  of  maintenance  and  training,  as  well  as  a  host  of  new 
applications  yet  to  be  defined  but  now  feasible  due  to  the  superior  technology  of  the 
bit-mapped  workstation  display. 

C.  LCCDS  FINAL  CONSIDERATIONS 

One  of  the  most  serious  problems  that  has  faced  the  weapon  system  acquisition 
process  is  the  lengthy  period  of  time  (10  years  is  not  uncommon  for  large  systems; 
between  initial  requirements  analysis  and  delivery  of  a  useable  system.  As  a  result 
the  computers  associated  with  these  systems  are  usually  obsolete  years  before  the 
rest  of  the  system  is  finished. 

While  there  may  be  no  reasonable  way  to  speed  up  the  acquisition  process  for 
large  systems,  we  can  avoid  being  stuck  with  expensive,  antiquated  computers  by 
delaying  the  acquisition  of  computing  resources  until  the  very  last  stages  of  system 
development  whenever  possible.  The  system  design  should  be  modified,  or  left  open, 
throughout  development  to  take  advantage  of  rapidly  improving  commercial  computer 
technology,  hardware  and  software.  Specifically,  we  should  take  advantage  of  the 
more  advanced,  reliable  and  less  expensive  commercial  workstation  systems.  The 
savings  seen  in  hardware  costs  alone  could  open  new  avenues  of  software 
development  for  efficient  use  of  current  computer  technology. 

The  main  point  to  be  made  here  is  that  these  workstations  are  not  just  sitting  on 
someone’s  "drawing  board".  They  exist  and  are  available  in  ruggedized  versions  for 
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immediate  use  for  military  applications.  The  holdup  will  be  providing  reliable  software 
which  not  only  supports  the  requisite  CDS  functionality,  but  also  makes  efficient  use 
of  the  immense  power  provided  by  the  hardware. 

The  methodology  for  software  development  is  steadily  improving.  Better 
software  is  being  written  largely  due  to  increasing  usage  of  formal  modeling  of  system 
architecture,  computer  aided  software  engineering  (CASE)  tools,  rapid  prototyping 
and  reusable  software.  In  our  opinion  the  existence,  and  rapidly  growing  availability, 
of  these  tools  and  methodologies  will  significantly  streamline,  economize  and  speed 
up  the  software  development  process.  The  key  is  to  develop  reusable  software  using 
formal  design  methods  and  automated  tools. 

There  are  several  advantages  to  this  reusable  software  approach  in  addition  to 
the  basic  development  time/money  savings  inherent  in  reuse  of  existing  systems. 
Different  systems  can  provide  the  operator  with  the  same  "look  and  feel"  via  a  shared 
MMI.  Experience  with  one  system  becomes  useful  for  cross-training  on  many  other 
systems.  Configuration  control  can  be  enforced  by  making  the  software  available  as  a 
toolkit,  i.e.,  object  code  is  available  for  use  in  any  desired  application,  but  the  toolkit 
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itself  cannot  be  tampered  with. 

The  LCCDS  would  be  a  great  project  on  which  to  apply  the  above  principles. 
There  is  a  lot  of  related  or  parallel  effort  in  the  area  of  command  and  control 
software.  In  the  case  where  the  different  systems  use  compatible  hardware,  they 
should  also  use  compatible  software  for  implementation  of  the  similar  functions. 
LCCDS  and  NCCS-A  serve  as  a  good  example. 

The  LCCDS  and  NCCS-A  systems  manage  the  same  basic  data  objects  and 
share  many  similar  functions.  In  our  view  the  central  LCCDS  issue  is  the  MMI,  at 
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least  for  the  early  phases  of  development.  While  there  are  some  critical  differences 
between  C2  and  CDS  systems  such  as  real  time  performance  and  control  of  external 
systems,  there  seems  to  be  no  reason  why  the  MMI  for  each  could  not  be  identical, 
and  obvious  economic  and  training  related  benefits  if  they  are  identical. 

Specifically,  NCCS-A  and  LCCDS  will  be  developed  for  microprocessor  based 
workstations  with  extensive  use  of  commercial  software.  Much  of  the  software 
already  developed  for  NCCS-A  is  directly  applicable  to  LCCDS  requirements,  most 
notably  the  MMI. 
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APPENDIX  A 


In  order  to  provide  a  more  complete  picture  of  the  Low  Cost  Combat  Direction  Sys¬ 
tem  project  we  include  here  a  copy  of  the  original  Statement  of  Work  issued  as  Enclosure  1 
to  the  NAVSEA  letter  [Ref.  4j  which  initially  introduced  NPS  to  the  LCCDS  concept.  We 
used  this  document  as  the  cornerstone  of  our  requirements  analysis  for  the  LCCDS. 
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Enclosure  1 


STATEMEN  I’  OF  WORK 
for 

LOW  COST  COMBAT  DIRECTION  SYSTEM  (LCCDS) 


Background 

Combat  Direction  Systems  have  been  in  an  evolutionary  development 
cycle  since  1958.  Early  systems  provided  basic  ship  to  ship  data  link 
capability,  analog  to  digital  conversion  of  tactical  data,  and  manual,  rate 
aided,  tracking.  Todays  systems  have  progressed  to  a  level  of 
sophistication  that  includes  upwards  of  20  tactical  interfaces  including 
multiple  tracking  sensors,  multiple  weapons  interfaces,  electronic  warfare 
and  multiple  tactical  data  link  systems.  Along  with  this  increased 
capability  has  come  increased  processing  requirements  and  the  need  for 
greater  sophistication  in  tactical  display  capability  which  in  turn  has 
greatly  increased  the  cost  of  fielding  new  Combat  Direction  Systems. 

Recently  the  Navy  has  initiated  what  is  called  the  Next  Generation 
Computer  Resource  (NGCR)  program  which  is  a  cooperative  effort  between 
Navy  and  industry  to  field  a  set  of  state  of  the  art  computers  for  shipboard 
use  in  the  late  1990  s.  Compatibility  between  the  various  computers  will 
be  through  standard  protocol  rather  than  through  common  instruction  set 
architecture  or  form-fit-function  replaceability.  Although  the  standards  for 
NGCR  computers  are  not  yet  fully  specified,  features  will  include  the 
following: 

a.  32  Bit  ISA 

b.  1  -  100  MIPS  performance  depending  on  application  requirement 

c.  26,000  hour  Mean  Time  Between  Failure 

d.  One  or  more  of  the  industry  and  government  back  plane  bus 
standards  including  VME,  IEEE  896  (FUTUREBUS),  IEEE  1296  (Multibus  II), 
and  VHSIC  Pi-Bus 

e.  Three  types  of  local  area  networks  to  choose  from  depending  on 
the  application  requirement.  These  include:  SAFENET  I  (< 1 0  Mbps), 
SAFENET  II  (>100  Mbps),  High  Performance  LAN  (~1  Gbps). 

f.  Network  Data  Base  Management  System 

Therefore,  any  computer  system  that  meets  these  protocol  requirements, 
as  well  as  the  DoD  ruggedization  requirements,  will  qualify  as  an  NGCR 
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candidate.  In  preparation  for  NGCR  availability,  NAVSEA  wishes  to  gain 
some  experience  in  the  development  of  Combat  System  software  on 
commercially  available  machines  that  meet  the  above  standards. 


Task  Description 

Implement  the  basic  features  of  a  Combat  Direction  System  on  a 
commercially  available  microprocessor  workstation. 


Specific  Requirements 

The  Navy  desires  to  develop  a  low  cost  Combat  Direction  System  (CDS) 
that  can  potentially  be  installed  on  non  combatant  ships  or  to  augment  the 
processing  capability  on  board  current  CDS  -  equipped  ships.  An 
incremental  approach  to  the  overall  system  development  will  help  insure 
that  this  effort  provides  maximum  benefit  to  the  Navy  in  terms  of 
experience  and  potential  end  product  use.  A  total  of  five  increments,  with 
a  demonstration  at  the  end  of  each  increment,  will  result  in  a  continuously 
improving  product  that  reflects  the  desired  features  of  the  CDS  community. 
The  specific  features  of  the  five  increments  are  detailed  in  the  following 
paragraphs. 

Increment  One  -  Select  the  computer  system,  run-time  operating 
system,  and  software  support  environment  for  the  LCCDS.  Design/develop 
or  select  an  existing  object  oriented  data  base  manager  that  interacts  with 
the  entire  CDS  data  base  (as  it  gets  defined)  and  allows  the  user  to  define 
new  objects  that  are  not  part  of  the  CDS  data  base.  The  data  base  manager 
should  provide  features  for  data  entry,  user  friendly  query  language  for 
building  logical  and  arithmetic  relationships  between  data  base  elements, 
and  a  powerful  output  generator  for  developing  display  screen  and  hard 
copy  formats.  Design/develop  a  display/graphics  capability  which  interacts 
with  the  data  base  manager  and  provides  the  user  with  the  building  blocks 
necessary  to  define  his  own  customized  screen  formats  for  interactive 
operation  of  the  systm..  Display  features  should  include  but  not  be  limited 
to  the  following: 

a.  Windows  and  pull  down  menus  for  operation  of  all  program 
features  including  the  operational  features  such  as  mode  selection,  range 
scale,  track  information,  help  commands,  display  doctrine  activation  and 
deactivation. 
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b.  Window  and  pull  uown  menu  selection  controlled  via  mouse, 
trackball,  light  pen,  touch  screen  or  any  other  feature  deemed  useable  by 
the  developer. 

c.  Graphics  capability  to  display  all  symbology  defined  in  enclosure  4 
of  this  package. 

d.  Ability  to  overlay  the  track  and  ownship  position  portion  of  the 
display  with  world  vector  shoreline  maps  as  available  from  the  Defense 
Mapping  Agency  (DMA). 

All  pull  down  menu  options  and  window  spaces  should  be  directly 
coupled  with  the  data  base  manager  such  that  all  information  can  be  user 
defined  and  changed  as  required.  That  is,  the  display  capability  should  be 
built  in  a  generic  fashion  such  that  the  user  can  tailor  all  display 
presentations  including  all  pull  down  menu  options  and  window  spaces 
effectively  building  a  new  run  time  Man  Machine  Interface  (MM1)  as 
desired. 

Display  doctrine  is  a  feature  which  enables  the  user  to  define  the 
conditions  under  which  data  will  be  displayed  and  how  to  present  the 
displayed  data.  Doctrine  statements  should  be  IF  -  THEN  -  ELSE  type 
statements  where  the  IF  clause  provides  for  operations  on  tactical 
information  such  as  type,  speed  and  bearing  of  tracks  to  be  displayed.  The 
THEN  clause  provides  for  the  data  presentation  such  as  blink  the  symbol, 
enlarge,  bold  type,  etc.  Doctrine  should  be  simple  to  define  and  easily 
activated  or  deactivated.  Doctrine  statements  should  be  allowed  to  be 
defined  individually  and  combined,  if  desired,  into  a  doctrine  tree  which 
consists  of  up  to  about  twelve  separate  statements.  The  IF  clause  of  a 
doctrine  statement  should  allow  for  at  least  twelve  qualifiers. 

The  general  response  time  to  any  user  selected  display  option  should  be 
no  greater  that  one  half  second. 

Increment  Two  -  Integrate  a  Manual  Tracking  and  Identification  (ID) 
capability  to  the  basic  display  capability.  Manual  Tracking  and  ID  refers  to 
the  ability  of  the  system  user  to  build  and  display  a  set  of  geographically 
stable  and/or  moving  points  of  information  of  the  position  portion  of  the 
display.  Manual  Tracking  and  ID  will  include  but  not  be  limited  to  the 
following  features: 

a.  Maintain  the  ownship  symbol  in  the  center  of  the  position  display 
at  all  times. 

b.  Introduce  a  standard  display  symbol  (see  enclosure  4  of  the 
package)  at  the  current  location  of  the  cursor.  All  symbols  should  be 
maintained  relative  to  the  ownship  symbol. 

c.  Allow  user  to  assign  a  speed  and  bearing  to  a  vehicular  track. 
Display  a  proportioned  speed  leader  on  the  track  and  change  its  position  at 
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least  once  every  4  seconds.  Track  position  should  be  dead  reckoned  using 
the  current  track  bearing. 

d.  Allow  user  to  assign  additional  information  to  any  type  of  track. 

e.  Allow  a  currently  displayed  track  to  be  hooked  (selected)  and 
display  selected  additional  information  in  a  window  (e.g.  for  a  hooked  air 
track  display  speed,  bearing,  type,  route,  etc.).  This  additional  information 
will  be  an  object  from  a  user  defined  window. 

f.  Allow  user  to  change  the  ID  of  a  track,  (e.g.  from  unknown  to 
friendly). 

g.  Provide  for  an  expandable  track  file  with  no  artificial  size 
limitations. 

Increment  Three  -  Integrate  a  receive  only  Link  11  capability  which 
provides  for  the  receipt  and  display  of  track  information  from  the  Ship  to 
Ship  digital  data  link.  This  increment  will  entail  the  development  of  an 
interface  to  a  Link  11  system  via  NTDS  protocol,  parsing  link  messages  and 
displaying  parsed  track  information  on  the  position  display.  It  is  not 
expected  that  the  LCCDS  will  package  and  ship  locally  generated  tracks  for 
output  on  the  data  link.  This  will  be  a  receive  -  only  system.  The  specific 
format  of  the  Link  1 1  data  is  specified  in  a  classified  Interface  Design 
Specification  (IDS)  and  Operations  Specification  and  will  be  provided  under 
a  different  cover.  For  quote  purposes  assume  twelve  message  types  and  six 
variations  on  each  message  type.  NTDS  interface  boards  are  commercially 
available  and  will  not  require  a  hardware  development  effort. 

Increment  Four  -  Integrate  an  ownship  maneuvering  capability  which 
includes  navigation  capability  and  track  interface  information.  Ownship 
maneuvering  will  include  but  not  be  limited  to  the  following: 

a.  Allow  for  the  specification  of  up  to  six  steaming  routes  with  up  to 
50  waypoints  (destinations)  per  route. 

b.  Provide  Closest  Point  of  Approach  (CPA)  geometry  from  ownship 
to  any  track  and  between  any  two  tracks.  Display  bearing  lines  on  the 
position  display. 

Increment  Five  -  Integrate  an  organic  auto  tracking  capability  using 
the  (TBD)  radar  interface.  This  task  entails  the  development  of  an  interface 
to  a  ship  mounted  radar,  parsing  the  input  information  and  displaying  the 
radar  contact  information  of  the  position  display.  This  feature  should  not 
be  costed  at  this  time  but  the  implementation  should  be  considered  for 
easy  add  on  at  a  later  date.  A  radar  IDS  will  be  provided  under  a  different 
cover. 
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